Nice write-up.
> Screen offers a multi-user mode which allows to attach to Screen sessions owned by other users in the system (given the proper credentials). These multi-user features are only available when Screen is installed with the setuid-root bit set. This configuration of Screen results in highly increased attack surface, because of the complex Screen code that runs with root privileges in this case
I wasn't aware of such a feature but I guess it's what makes stuff like tmate possible. Speaking of which, I wonder if tmux is affected by the same kind of vulnerability.
Note: In Debian, GNU screen is not installed with setuid-root privileges.
And the package in Debian Stable (aka bookworm) is too old to be affected by the vulnerabilities in 5.0.0.
I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)
Debian stable users missed heartbleed entirely. I think the glacial pace is underrated.
Glacial page bedrock of an OS with optional sandboxed more-up-to-date userspace packages and runtimes that can be layered on top of the host system was the dream of flatpak/snap/appimage, right?
Yes, though that comes with its own headaches since the data those sandboxed applications are supposed to touch are the only actually valuable data on my computer. (How many versions of OpenSSL are currently running on my Silverblue system? I literally couldn't tell you.) My spreadsheet is only vouched for by some random dude on Flathub and it can steal all my financial information. But at least it can't add a printer, or delete a system file that I can freely download from the Internet at any time.
Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096
If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
This is about Mozilla's builds of Firefox for Debian, not Debian's builds, right? So regular Debian users who run the default Firefox (firefox-esr) would be unaffected.
To be clear for the sake of other readers, Debian's firefox-esr package is Firefox.
It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.
https://support.mozilla.org/en-US/kb/choosing-firefox-update...
The repo appears to be working for installing/updating packages. Mozilla should allow file listing which should fix the 404s, and make this repo behave as expected when manually browsed (Apparently hosted on a Google webserver; maybe Google forbids this?).
apt-get changelog firefox
Get:1 store: firefox 138.0.3~build1 Changelog
Fetched 129 B in 0s (0 B/s)
firefox (138.0.3~build1) UNRELEASED; urgency=medium
* N/A
-- Mozilla <release@mozilla.com> Mon, 12 May 2025 12:40:33 -0000
date
Tue May 13 08:56:09 AM PDT 2025
apt-get install --download-only --reinstall firefoxI will have to look into that more tomorrow. My only Debian desktop is a laptop at family's house and currently asleep. It mentioned an error with the repository but my first troubleshooting step was to try to manually verify I could _get_ to the repo in a browser.
Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.
https://jdebp.uk/FGA/unix-login-database.html
The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.
The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.
Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.
* https://skarnet.org/software/utmps/
Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.
I set TMPDIR to $HOME/tmp because of that.
I know; but it mitigates some potential race conditions.
Slackware 15:
lrwxrwxrwx 1 root root 12 Feb 11 2022 /usr/bin/screen -> screen-4.9.0
-rwxr-xr-x 1 root root 455016 Feb 1 2022 /usr/bin/screen-4.9.0
no suid
FWIW, Slackware 15 was updated to screen to screen-4.9.1.
This update fixes security issues:
* attacher.c - prevent temporary 0666 mode on PTYs.
* avoid file existence test information leaks.
* socket.c - don't send signals with root privileges.
Looks like it is in Fedora.
On Fedora it is setgid screen, not root.
Likewise in Arch.
I wonder if there is some selinux policy to reduce the attack surface
There almost certainly is, pretty sure Fedora has an SELinux policy for all software in base.
Everyone I know has switched to tmux a long time ago. Screen is obsolete and shouldn't be used
Here's the rendered blog post:
https://security.opensuse.org/2025/05/12/screen-security-iss...
I emailed the author of GNU Screen about the lack of proper documentation about the logging to a file feature:
http://www.zoobab.com/screenrc
GNU need a better issue tracking system :-)
There was a Q&A with the author of Tmux. He was complaining about the lack of documentation ~16 years ago.
Tmux has been in OBSD base side several releases and documented since the first one.
I know. I suggest you read the Q&A I posted.
It's surprising that upstream was involved in this. Around 5 years ago, I came to the (sad) conclusion that GNU screen development had completely halted. Is that still not the case?
Does screen have the functionality to add a new window to an existing screen without attaching to the screen yet?
Upstream requested that the SUSE team take a look at it. It seems that development is understaffed and the upstream may not have the expertise to maintain it properly. Which, if true, is sad -- I know that tmux and others exist, but a lot of people have used Screen for many many years. It sucks when a tool bitrots.
Looks like a tech-debt ridden large piece of software that new developers just can't understand.
If that's the case, it's not really about it being "understaffed". Instead, it's doomed to rot until it's replaced of rewritten. There's no scenario where more maintainers will help, except for marginally delaying it.
The good news is that there are almost perfect replacements out there, and most of them are leaner.
Instead, it's doomed to rot until it's replaced of rewritten.
I've seen how that mindset has ruined several companies. Not saying that you're wrong about that particular program that is, after all, free software replaced by other free software parts. But for business, it's lethal.
Joel Spolsky had a nice piece about it:
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
That and Fire and Motion seem to be forgotten wisdom already:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
I feel old :-)
It's not large:
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
What are the replacement tools I should be looking at as a casual user of screen?
If there was a way to get rid of Tmux's persistent status bar, I'd be happy to switch over. But last time I checked, you can't, and I want that real estate.
tmux is great but it's way too powerful for the 90% use case of screen - which is "let this process continue to run even if I disconnect or logout".
I've had some luck with mosh, but that also seems kind of moribund.
For my use case it's fine.
Involved only insofar as shipping it as setuid-root counts. Distros that configure it like this are vulnerable, others aren't. Very thin involvement I'd say. Distros patch if upstream is too slow.
TFA says upstream asked for the review.
Right, I got the direction wrong.
"TFA"?
The Fine Article
It’s not necessarily sad for GNU tool development to stop (other than bug fixes, of course). I would take that as a sign that they are basically complete.
Not quite in this case. Tmux was started by someone who wanted to update screen with new features but wasn’t able to bend the code that far. I say this not out of spite or meanness, as I used screen for many happy years, but I’d say it’s less complete and more abandoned. It still has maintainers but it seems to me that they’re more “keep the lights on” than actively developing it.
It's not sad if a good Stallman-free alternative exists. Like tmux.
screen didn't even have vertical splits until maybe 5 or 10 years ago. After tmux was already a solidly reliable replacement with vertical splits for years.
True, this is why I switched to tmux.
Whether constant development is necessary or not largely depends on the surface area of your tool, both in terms of formal APIs it uses and external data formats and services.
> Due to difficulties in the communication with upstream we do not currently have detailed information about bugfixes and releases published on their end.
It sounds like they requested the security review, but have been difficult to keep in touch with? I'm not sure what the whole story is there.
Seems like a prime target for Jia Tan.
Yep, from the timeline it looks like lack of communication (and maybe also capabilities/resources/time/will, not sure) [0]
0: https://security.opensuse.org/2025/05/12/screen-security-issues.html#8-timelineOpen source does have a problem with inertia whenever one piece of software ends and another piece is created to replace it, but there's no immediate incentive to switch, because it is a switch, not an update.
Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.
> Though conversely, when someone buys the trademark for an existing piece of software, and replaces it with something entirely different, like what happened with Audacity, that's also bad. So there's no good solution.
I've followed the Audacity situation over the last few years. Before the Muse Group bought the rights to the trademarks and took over development, Audacity development had pretty much stagnated.
The new developers did not replace it with something entirely different. What they did was fix longstanding bugs and add new features/enhancements (and changing the way some things work, for better or worse). Sure, they introduced new bugs here and there with the new features/enhancements, but last I checked they fixed those. And yes, they could have done a better job at marking new versions as "beta" rather than pushing them out as stable releases (old hands know to avoid a new version until a couple minor versions later). That's really my biggest gripe with their development/release process.
They are completely redesigning the UI to such an extent that it may as well be a completely new project.
Also, how come open source names can even be bought? They should be open, of course, so I think it'd be fair enough if they wanted to call theirs "MuseScore Audacity" or something like that.
The good solution is rock-solid, backwards compatible APIs on all levels. That way the work to maintain software would be much lower, making it possible to focus on doing some rare bug-fixing only. In open source in particular this should be a no-brainier, instead of all projects ruining things for each other by ignoring backwards compatibility.
The rock-solid backwards-compatible API would include, for example, being invoked with the command "screen -x", and being installed with "apt install screen" - at which point it's the same screen project under different management, not a new project.
I was referring to the APIs required by screen itself to run. If screen is anything like any software I know anything about a fair amount of limited developer time has to be wasted on keeping up with random third-party stuff changing/breaking. Even if that is not the case, if we get more stable software in general that would mean maintainers of free software could take on more projects each, meaning there would be a higher probability that someone could be around to fix bugs in screen.
Isn't this what distros are for? So e.g. Debian could decide to replace screen with tmux, possibly with some sort of compatibility package that takes all the same command line arguments as screen but uses tmux under the hood. (I've used screen very little and have never used tmux so I'm not sure if that would make sense in this context).
You generally can’t transparently replace a tool by a different one like that, siblings are giving examples of where there would be incompatibilities. There would also be much upheaval among users if a distribution would try to underhandedly perform such a replacement. If anything, a package “tmux-as-screen” could be provided for those who want that.
In that case, nobody would be tricked because they would have to explicitly select that package. Those already having screen installed, or selecting screen for installation, wouldn’t automatically be upgraded to tmux-as-screen. So what the comment you replied to mentioned as a problem of inertia and there being “no immediate incentive to switch” would remain largely unaddressed.
A smooth transition from GNU screen to tmux, will be appreciated for potentially 60K users.
https://qa.debian.org/popcon.php?package=screen
I note that tmux has only 40K users (of debian popcon users)
https://qa.debian.org/popcon.php?package=tmux
I am considering to try the link shared previously:
https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...
Now I miss a way to translate CLI options and batch files
You can reconfigure the key-bindings, that I guess would be the largest annoyance for a new user. But there are many fundamental differences between them that you just can't hide.
Tmux doesn't support serial ports.
It's not separate functionality. The back end (so-called "master" side) of a pseudo-terminal is almost (bar initialization of line speed, hardware flow control, and framing settings) indistinguishable from a "null-modem" call-out serial port or parallel port terminal device. Write a software terminal emulation program for the former, which of course is what screen has, and you already have one for the latter.
It isn't separate functionality. Terminals connected via serial port is a valid use case for a terminal multiplexor.
When most people use the term "serial port" they're referring to a DB-25 or DE-9 port you find on older computers or USB dongles. It's also seen in 8P8C (aka "RJ45") form sometimes, especially in industrial equipment. It can send and receive "characters" (anywhere from 5-8 bits each) one at a time at a fixed rate, either half duplex or full duplex. They usually implement one or more of the RS232, RS422, or RS485 standards.
Originally, you communicated with the computer using a teletype or video terminal connected to a serial port. Whatever you typed went to the computer, and whatever the computer sent back was printed on your terminal screen (or paper in the case of a teletype).
The UNIX (and thus, Linux) command line environment still works this way, except the serial line is virtual.
It is a port that has two data lines, RX and TX, and data is sent in a serial fashion across those data lines. It is used today for embedded systems, routers and switches et al, and getting a console on any machine that doesn't have a gpu with a monitor attached.
USB is a serial BUS, which allows multiple devices; serial ports are single device (if my memory serves).
console=ttyS0,115200
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
> The observed behaviour has been present in Screen versions since at least the year 2005.
and it's been an anti-pattern and covered by tools like rkhunter for around least that long, as well
but pretty sure screen was setuid root in the 90s too
Rendered version: https://security.opensuse.org/2025/05/12/screen-security-iss...
tmux is in OpenBSD base since 4.6 IIRC and is/has been audited. It's a good alternative for those who want something a bit more secure.
Seeing screen popup reminded me of that one time I switched to tmux and forgot to use screen.
1. How many developers run all the most popular open source tools?
2. How much money is in the industries that use those tools?
Zellij is a really nice, modern alternative to screen and tmux, and they've done a great job at having good defaults as well as making the UI easily discoverable. I'd highly recommend it to anyone else who felt dubious about the benefit-to-effort ratio of terminal multiplexers.
Last time I looked at Zellij it looked like a great new project in the multiplexer ecosystem, but didn't support a purely keyboard-driven copy/paste mechanism. I use that extensively and couldn't do without. So tmux it is until that gets added.
I gave it a shot a couple years ago -- pretty slick. But the latency was noticeable compared to tmux, which I remain using today. I admit that I'm kind of sensitive to it, as at the time I was already on a latent connection.
I personally haven't noticed that, but we all have different sensitivity levels to such things. Have you tried it more recently? A couple years ago is ancient in its lifespan. I'd be curious to see if it still feels sluggish to you.
(Not a dev, just another end user.)
No, haven't tried recently, but will make a note to do so. Agree that a couple of years is an eternity :)
Right on. I'd love to hear back about that.
It could also be in my case that I use it so little that some latency is tolerable. I don't develop interactively in zellij or tmux. I mainly keep some logs tailing, and DB consoles open, etc, and I don't check them super often.
Funny you should mention screen and setuid. In one installation, I had to give screen chmod u+s perms to solve some weird issue, thinking what a gross thing to do.
Turns out, it has features dependent on setuid, and some systems ship it that way? Yikes!
(But, after I gave u+s to screen, it reads root's ~/.screenrc instead of mine (which I accepted as part of the workaround). Maybe that particular build of screen I'm using doesn't react properly to setuid; maybe it has to be built a certain way also to enable that support.)
Nope, that's exactly how setuid works. You're setting the [s]pecial bit on a binary to tell the system to always run it as the provided [u]ser
Nope, setuid programs have an effective UID as the owner (often root), but also have the real user ID of the original user. Programs intended for setuid operation pay attention to this; it is very important. They can use to to perform certain operations under privilege and then permanently drop to the original user.
What advantages does screen offer compared with multiple tabs in your terminal emulator?
The terminal sessions will persist even if your emulator crashes. Or, if you ssh into a machine you can use multiple terminal sessions from a single connection, and you can disconnect and reconnect to those sessions later.
There's a few other features like a common clipboard of sorts, monitoring a session for silence/activity, but those could all be provided by your emulator.
I use it for running some multiple-hour jobs on a remote VM.
I use byobu (for the keybinds) on top of tmux. But Zellij (modern Rust-based alternative to tmux) has been looking quite interesting for a while.
So ... my tmux lifestyle is objectively superior in this one respect. Excellent.
Yes, that's why all the cool kids switched to tmux 17 years ago. The only argument the screen camp had was "no serial port support in tmux". To which we answered something about a smaller more modern code base...
I found it incredibly slow, especially running Neovim. Zellij was missing super basic functionality, so I went back to screen.
I switched to tmux and I switched back due to the weird server/session/window/pane model that makes no sense and prevents me from showing different windows or layouts on different clients. 4 levels of objects is ridiculous and when you end up with less capabilities than screen, what are we doing?
I would love to switch to a modern, maintained terminal multiplexer, but it would need to, well, be good at multiplexing.
I haven’t done serial port stuff in many years, so I ask this in ignorance and I give you permission to laugh at my naïveté. Can’t you just run tip or something in a tmux or zellij window and have basically the same thing?
> The only argument the screen camp had was "no serial port support in tmux".
No, the screen camp has the valid argument that licenses matter and tmux is not GPL software.
From the end user perspective, it makes zero sense to avoid software just because it has an open source license that is more liberal than GPL.
You seem to completely miss the point of the GPL.
Are there any official RedHat CVE pages for any of these screen vulns yet? Haven't found anything so far
RedHat removed screen from the distro repos starting from RHEL8 and recommended tmux as the replacement.
It's still in EPEL I think but I guess that releases RH from having to address it?
That's right. EPEL is not an officially supported repo.
Setuid binaries existing in 2025 is not acceptable. There needs to a movement to remove all of them as time and time again it's shown that it leads to severe vulnerabilities.
If you're worried about security, A less than 10k lines of SOC is your aim. mtm, abduco, dvtm achieve this. screen? Impossible for it to ever be secure. You'll be playing an endless game of whack-a-mole.
lines of code is a measure of complexity in your argument; its better to call it that. Increased complexity, depending on the language, isn't necessarily lines of code, but can have the same effect
so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
[dead]
Can screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?
In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
Then:
Unix: Small, light, mediocre OS for underpowered microcomputers. Either crash silently, or cut down the bloat.
MIT/GNU: Correct systems first. Plenty or resources. Lisp. Detect the errors, fix and step over them, continue the process.
Now:
GNU=Ugly bloated umUnix like, mega light Elisp editor but s l o w and prone to lock. Good FS' on Linux. FDo it's mainly Red Hat bloatware. Screen does too much.
OpenBSD=Correctness, ISC licensed mainly. Unix bound, small tools, but so-so FFSv2. Sndio works. Audio, video and so on perms work, no DBUS needed. CWM it's really fast and much easier than I3. Dumb config, fvwm looks like rocket science. Tmux, no screen(1) except for ports. Snappy, easy to config and script. Use damn cu(1) for serial, thanks.
[dead]
Only tangentially related, but I'm always fascinated that mailing lists are still a thing in 2025.
Please, inform us of an alternative which is:
• Non-proprietary
• Federated
• Archivable
• Accessible
• Not dependent on a specific company
- horrible usability
- can only participate in conversations via e-mails
- unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
- NOT accessible, especially in the disabilities sense
- doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
- no responsive design, tiny text and horizontal scrolling on mobile phone screens
- sends you your password in cleartext via e-mail
- actually complicated to unsubscribe from a list / manage your membership
> - horrible usability
The web has horrible usability if you use a text-based browser. I.e. if you use a mail reader with good usability, a mailing list has good usability. This is a client-side issue, not a technology issue.
> - can only participate in conversations via e-mails
Um, yes, a mailing list uses e-mail. I don’t know what you expected.
> - unclear how to participate in / reply to an older thread that wasn't delivered to your mailbox
If you are a new user, and want to reply to a mail you read in the list archive, just write a new mail; there is no strict rule that any discussions must be restricted to one thread.
Indeed, if you want to start a new discussion after some time has elapsed, a new thread may be preferred.
> - NOT accessible, especially in the disabilities sense
Again, this is a client issue. I believe that e-mail is actually the preferred form for those with accessibility needs.
> - doesn't have a search feature; depends on external search engines to crawl the mailing list for discoverability
Somewhat true, but this depends on the list – some list archives do feature search – and is very rarely a problem in practice, since external search engines are very efficient.
> - no responsive design, tiny text and horizontal scrolling on mobile phone screens
Again, a client issue. Get a better e-mail client.
> - sends you your password in cleartext via e-mail
Yes, many lists do this, but this is not a requirement of the technology. Some lists could require all your mails to be signed with PGP or S/MIME; it is entirely up to the list.
> - actually complicated to unsubscribe from a list / manage your membership
Not really. The ”List-Unsubscribe” header is commonly sent in every mail to the list.
I wasn't criticizing the use of them, I just find it fascinating that we still use them. They'll probably still be around in some form in another 3 decades.
Email is a root-of-trust for authentication in most non-email systems.
GIT promised to be "Non-proprietary, Decentralized" but still does not have a built-in issue tracker :-)
GIT is non-proprietary and decentralized so it keeps that promise.
And having a built-in issue tracker
1. isn't related to those properties, and
2. isn't truly within the scope of a source code version control management solution.
That's the domain of project management.
Fossil has one. If its something you want use Fossil - which I think is a great alternative for small teams, on the other hand, this is probably not something large teams (which are a high priority for git) want.
If I ever get around to writing my git issue tracker, everything will be stored in a completely separate reponame-issues.git
Shouldn't the git native issue tracker be as simple as adding file pr/the_problem_i_am_having
Issues shouldn't really live in the same source tree, IMO. But AFAIK there are forges that keep the issues in the same repository, just not in the same tree of commits that the source tree has, git notes style.
Any user without commit permission should be able to create tickets and comment on them.
What's wrong with debbugs? :)
For large projects like the Linux kernel as an example out of many, I would assume the built-in issue tracker would end up 100x the size of the code base in storage space. lol
My qualm against them is rather different. Why, after so much time, are they still so user-hostile, both in their web appearance and more generally usage?
It's rhetorical of course, it's because their users are completely blind to their pitfalls after decades of use, and it seems that generation-renewal is not a priority.
Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week.
I don’t think GitHub adds that much over using and contributing to software. I generally prefer when the project have its own website and a proper about and documentation section.
As far as contributing go, coding a bug fix or a new features takes way longer than figuring how sending patch over mail works (for the extreme case) and you only need to do it once.
And opensource is not a popularity contest.
"Discord servers and other contemporary solutions are much worse on the long run, but it does not matter. Software is like startups, long term is not a goal when you are not sure to survive (or in that case, being used and having contributors) next week."
I don't think I've read anything that I disagree with so strongly in a while. "Software is like startups" is about as user and contributor-hostile a concept as they come.
The long term absolutely matters and projects choosing convenience today over long-term thinking are screwing over their future. It's damn near impossible to find information about these projects outside the proprietary silos they've dug themselves into and they will regret the choice one of these days when Discord or whatever proprietary service starts tightening the screws to make money.
I'm not sure what you find hostile about their web appearance. It's a light, clean page with text that doesn't throw tons of JS at you, pop-ups, or a cookie accept/reject/ponder bullshit dialog. It could use a bit of a copy edit / redo and a screenshot (I always complain when a project doesn't have screenshots...), but I don't find it hostile in the least.
Try opening that link on a phone. You get tiny, hard-to-read text because of course it's monospace with hardcoded line breaks.
GP's point is that convenience and long-term thinking don't have to be an either-or. We should have convenient tools that don't require proprietary silos but work well on today's devices and with today's use cases.
Yes, ideally for a web archive the text should be flowed and styling responsive. That’s a flaw of the web site not the use of email lists.
> The long term absolutely matters and projects choosing convenience today
I would be happy to engage on that thought, but here on this thread there is a lynchmob gathering to declare an emergency to remove all GPL-connected code everywhere, again.. because `screen`
I’ve never used a discord server and would not know how. If that’s the communication channel you choose, I’m out.
I have and can, but I strongly prefer not to, and will generally just avoid it altogether.
If I wanted to use IRC, I’d use IRC.
A mailing list is just a kind of public group chat. You're probably in many public group chats, including this one right now. Mailing lists, IRC, traditional web forums, Discord, WhatsApp are all implementations of the same basic concept.
Like any implementation, it comes with certain affordances which differ from other implementations.
Messages feel "heavy" for several reasons: sending one involves a lot of clicks (or keypresses); if you send a very high number you may be banned from your email provider, and unable to communicate with anyone.
Messages often arrive instantly, but can be delayed up to hours or days, so conversation round-trips are kept to a minimum.
Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Being off the web increases the barrier to entry, reducing the eternal september effect (ironically, Usenet is one of the least eternal-september-ish of the public discussion boards currently in existence).
Overall, the feel of the system tends to somewhat discourage quantity and encourage per-message quality.
> Messages are all the same - there are no "lite messages" such as emoji reactions - so any message must contain enough content to justify being a full-fledged message, or it won't be sent at all. (Sometimes an "emoji reaction" is felt to be enough content to justify a full-fledged message, which is sent.)
Haven't you heard about the abomination which is Office365? They recently bolted emoji reactions onto email!
I brought up some security issues similar to these years ago to the Screen community and they laughed at me saying I was being paranoid. Nice to see they're finally doing something about it.
No, tmux uses unix domain sockets. I have no idea why screen chose to take the setuid approach instead here; it seems totally unnecessary to have root privileges.
EDIT: Further down, TFA gives a plausible explanation: the current screen devs are not fully familiar with the code base. If so, the setuid-root approach was probably the easiest way to make the feature work in lieu of such familiarity.
screen has a lot of architectural baggage that can be traced back to its initial 1987 comp.sources.unix/mod.sources versions in some cases. Being set-UID to the superuser is one of them. See the doco for screen as it was posted in volume 10:
https://sources.vsta.org/comp.sources.unix/volume10/screen/
I guessed something similar. Screen is from an era where setuid was pretty common!
[flagged]
[flagged]
Screen is useful when you need to a nest multiplexing inside tmux.
And for serial ports
Try as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
Screens main use case is to open an emacs session remotely.
Tmux's main use case is to be glue for a unix IDE.
The two use cases are rather different and the tools are very specialized for them.
Same here (speaking more specifically about debian)
On my gentoo box it's setgid hmmm.
Ubuntu it's not set.
Nostalgia and novelty are powerful narcotics.
IDK Man the hammer I use today looks a hell of a lot like the hammer used by engineers throughout human history.
Engineers are rational people. Software developers calling themselves "engineers" are not.
True, it's not really as if it's a massive codebase
It's used a lot for legacy reasons I think. People didn't move to something newer like tmux because why would they? It's super handy to keep stuff running on a console while disconnected from it. In that sense it (or at least, tools like it) are indispensable.
Sysadmin types, often daily
The problems here are more about the architecture. You can write 100% memory-safe but completely insecure code in Rust, Java. Haskell, Erlang, Smalltalk, bash, you name it. For instance, running a setuid binary may add problems to code written in any language.
In the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root?
Edit: Yes, Screen 5.0.0.CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
screen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.
I remember installing screen on a SunOS box back in the early 90's. It's been around a longggg time.
I guess I'm glad that I switched to tmux ages ago.
It's a great feature! I have used it in training sessions by giving each student their own login on my laptop, with the ssh shell restricted to 'screen -x <specific user's window>' - the only window that user could use based on screen's ACLs. Then during exercises I (as the owner of the screen) could switch to each student's screen on the projector so the class could see what they had done.
Not surprised to hear it's full of security holes. :)
Yup, screen -x
The problem isn't with the use of `screen -x ...` itself, but rather if `ls -l "$(which screen)"` returns something like `-rwsr-xr-x 1 root root ... /usr/bin/screen`, where the `s` in the fourth position indicates the setuid bit is set. That means the screen binary runs with root privileges.
I am well aware of setuid. I was informing the parent comment of which arg to use for the actual functionality.
Often for long running jobs you want to see the status of where logging out of the system stops the job output.