> 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.
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:
Kind of nuts that a tool that hasn't fixed nearly 40-year old practices is in common usage among developers. Never tell me engineers are rational people.
* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.
* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.
* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.
* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.
* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.
For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
I hadn't used Zellij before, but I tried it out. Visually it works better than tmux and it shares enough key bindings with tmux to make it a pretty seamless transition.
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
True, but zellij also does more. I'd also give it more of a stink eye if it were something I were running many times inside the inner loop of a script, but as something you generally launch once and leave running forever, eh.
I occasionally have to recalibrate my units. I just launched Emacs on my Mac and it's using 350MB of RAM. That's astonishing when I think about Amiga programs I wrote, but it's also just 0.53% of the RAM in this particularly machine. It's probably larger than it could be if someone ruthlessly trimmed it back, but I'd rather spend that time using the other 99.4% of my machine to do more fun stuff.
I used to used zsh, like I still have have karma moving up on stackoverflow as I answered my own questions on some obscure configuration fine tuning. But currently I'm more in a "give me the thing that work off the shelf" moment, so I take fish and don't plan to either look back.
Byobu with tmux as backend is my go to solution if I want a multiplexer, for what it worths.
Definitely more of a fish vs zsh situation, in my opinion.
tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!
Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.
Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.
I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.
A quick example is that mouse scrolling works by default. I see it more like ripgrep vs grep. Either can do almost anything the other can, but one has much more modern, ergonomic defaults.
When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.
It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.
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.
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. :)
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.
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 :-)
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.
Correct, but that's firefox-esr not firefox. At one point I found it necessary to switch as there was an issue with security updates, but that might have been an issue in that particular system's configuration that I since resolved.
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
Or, to really prove it to yourself, you can re-download the package:
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.
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.
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.
I prefer the latter. It matches my mental model of such things, and lots of people talk about enjoying switching to it. Many others happily use the former daily.
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.
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.
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.
Open 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.
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 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.
I'm not sure what made "screen" integrate the two separate pieces of functionality - you can use something minimal like "tio" for serial port access and it's much more elegant.
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.
In theory you're correct, but by that logic you'd also have to add ssh (probably by far the most common way of connecting to a remote terminal today). I guess you'd end up with something like mobaXTerm which is a valid approach for sure, but doesn't compose as well.
Personally I live by the maxim "if it can be separated without significant drawbacks, then it should be separate" but GNU tends to see it differently.
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).
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
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.
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.
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 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?
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.
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.
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.
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.
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
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.
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.
"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.
> 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`
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.
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.
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/
Kind of nuts that a tool that hasn't fixed nearly 40-year old practices is in common usage among developers. Never tell me engineers are rational people.
It's a combination of factors:
* The original author of the project has not been involved in it since 1990. The people who took it over and made it a GNU project then largely stopped working on it in 2004. The people who are now working on it are something like its 3rd or 4th wave of developers.
* Learning the internals of screen now from scratch is a lot harder than when I did it in 1987. There's an awful lot more operating system historical and portability factors, now. In 1987, it was works-on-4.3BSD-might-not-on-your-Unix.
* If you deal with pseudo-terminals cross-platform, there are still huge variations on how pseudo-terminals work and how the long-standing security issues of pseudo-terminals, identified in the 1990s, have been addressed in operating systems.
* screen is encumbered by a lot of 1980s Think. It still today diligently manages, and puts quite a lot of effort into constructing, a generated-on-the-fly TERMCAP environment variable, for example.
* Attitudes to security have changed. At least one security hole in the headlined report was actually a neat-o feature of terminals in Unix in the 1970s and 1980s.
For me it felt (!) like screen is pretty much obsolute since 10+ years. When tmux came I switched and never looked back and I know a few that handled it the same.
A similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
I hadn't used Zellij before, but I tried it out. Visually it works better than tmux and it shares enough key bindings with tmux to make it a pretty seamless transition.
With that being said, the binary is huge. I get that zellij is statically linked, but tmux is about 900KiB and has minimal dependencies. I'm flabbergasted that a terminal multiplexer, stripped, is 38MiB.
Looking at the source code I assume it's just the amount of cargo deps. Some of which I'm not sure what place they have on a tmux at a first glance.
True, but zellij also does more. I'd also give it more of a stink eye if it were something I were running many times inside the inner loop of a script, but as something you generally launch once and leave running forever, eh.
I occasionally have to recalibrate my units. I just launched Emacs on my Mac and it's using 350MB of RAM. That's astonishing when I think about Amiga programs I wrote, but it's also just 0.53% of the RAM in this particularly machine. It's probably larger than it could be if someone ruthlessly trimmed it back, but I'd rather spend that time using the other 99.4% of my machine to do more fun stuff.
What does it do better than tmux?
Or is it more of a fish vs. zsh type of situation, where neither is obsolete, but the target audience is just very different?
I used to used zsh, like I still have have karma moving up on stackoverflow as I answered my own questions on some obscure configuration fine tuning. But currently I'm more in a "give me the thing that work off the shelf" moment, so I take fish and don't plan to either look back.
Byobu with tmux as backend is my go to solution if I want a multiplexer, for what it worths.
Definitely more of a fish vs zsh situation, in my opinion.
tmux, to me, feels like "modern screen". It has some cool features, but at the end of the day, it just wants to be a terminal multiplexer. Great!
Zellij on the other hand seems to offer terminal multiplexing as an obvious first-class use case but "not the whole point". At the surface, Zellij is an opinionated terminal multiplexer that uses a nice TUI to give discoverability which you can turn off when you're ready to gain screen real estate. It's easy to make Zellij behave exactly like tmux/screen, and it's easy to configure via a single config file.
Where Zellij takes a turn in to a different direction, however, is that the workspaces you can configure with it can do all sorts of interesting things. For instance I once built[0] a python cli app which had a command that would launch a zellij workspace with various tabs plugged in to other entrypoints of that same python cli, basically allowing me to develop a multi-pane TUI as a single python Typer app. In one pane I had the main ui, and then in another stacked pane I had some diagnostic info as well as a chat session with an llm that can do tool-calling back out to the python cli again to update the session's state.
I think wrapping up a project's dev environment as a combination of mise (mise.jdx.dev) and zellij or nix+zellij to quickly onboard devs to, say, a containerized development environment, seems like a really neat idea.
0: https://github.com/eblume/mole/blob/main/src/mole/zonein.py -- but this is mostly derelict code now, I've moved on and don't use zellij much currently.
A quick example is that mouse scrolling works by default. I see it more like ripgrep vs grep. Either can do almost anything the other can, but one has much more modern, ergonomic defaults.
Terminals are obsoleted by Arcan:
https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
From a quick read, all I can see is a manifesto for emacs.
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.
SvP https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...
Thankfully you can configure it. I had the same initial difficulty.
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.
Nah, screen's main use case is as an ad-hoc method to daemonise random scripts.
Yeah this is 100% of when I reach for screen. “I’m not willing/ready to make this a service, screen detach here I come”
I switched to dtach for the first case.
dtach for session persistence. “Do one thing well.”
> Screens main use case is to open an emacs session remotely.
Not an emacs user, but for this, what does screen do that tmux can't?
Nothing at all. I’ve used emacs over tmux (and now zellij) for many years. Emacsserver can replace both of them, but that’s a different story.
I'm confused by this statement. Are you claiming this is the projects' stated goal? Their primary use in the wild?
Emacs can work as a daemon.
It also has tramp mode which means you can use all your local packages remotely.
When I realized how powerful TRAMP was, I don't think I ever used screen/tmux again. I'm sure there are uses, mind. Just TRAMP fully hit all of my needs.
It really is magical, isn’t it? And although I rarely need to use it, I love the multihop setups where you can ssh to this system, then ssh again to this other, then mount an SMB filesystem using these credentials, and start editing.
Is it actually in common usage? I'm sure it's used by a lot of people, but it seems quite niche still.
Nostalgia and novelty are powerful narcotics.
We usually wait for a version written in Rust for this kind of cruft removal.
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.
On my sistems screen doesn't have setuid.
On my gentoo box it's setgid hmmm.
Ubuntu it's not set.
Same here (speaking more specifically about debian)
Engineers are rational people. Software developers calling themselves "engineers" are not.
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 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.
I was surprised to hear OP wasn't aware of it as it was the first reason I ever had to use screen (shared remote debugging session.)
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 :-)
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.
Correct, but that's firefox-esr not firefox. At one point I found it necessary to switch as there was an issue with security updates, but that might have been an issue in that particular system's configuration that I since resolved.
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?).
Or, to really prove it to yourself, you can re-download the package: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.
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
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
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.
https://undeadly.org/cgi?action=article&sid=20090712190402
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.
Here's the rendered blog post:
https://security.opensuse.org/2025/05/12/screen-security-iss...
Can screen just get completely tossed and converted into a compatibility-layer wrapper around tmux?
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.
What are the replacement tools I should be looking at as a casual user of screen?
If you want screen-but-better: tmux.
If you want a rethinking of the idea: zellij.
I prefer the latter. It matches my mental model of such things, and lots of people talk about enjoying switching to it. Many others happily use the former daily.
Tmux
It's not large:
https://git.savannah.gnu.org/cgit/screen.git/tree/src
A few 2kLOC files and the rest is rather small.
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.
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.
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]
Open 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.
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).
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.
I'm not sure what made "screen" integrate the two separate pieces of functionality - you can use something minimal like "tio" for serial port access and it's much more elegant.
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.
In theory you're correct, but by that logic you'd also have to add ssh (probably by far the most common way of connecting to a remote terminal today). I guess you'd end up with something like mobaXTerm which is a valid approach for sure, but doesn't compose as well.
Personally I live by the maxim "if it can be separated without significant drawbacks, then it should be separate" but GNU tends to see it differently.
I'm sure a rewrite of screen in Rust will be 105% secure. And won't support serial ports either.
What is a serial port and what do you use it for?
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).
Rendered version: https://security.opensuse.org/2025/05/12/screen-security-iss...
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
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.
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.
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.
https://zellij.dev https://github.com/zellij-org/zellij
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.)
1. How many developers run all the most popular open source tools?
2. How much money is in the industries that use those tools?
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 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.
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.
In 1990 we got told to stop using screen because other people could get into your sessions. Never used it again after that.
so it appears that packaged Debian `screen` is not installed with root execution, therefore this entire situation is not a problem on Debian?
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.
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
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.
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
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.
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.
> 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`
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.