7 ms·
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 privilege
by dooglius 1y ago
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.
- JdeBP 1y agoscreen 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/ https://sources.vsta.org/comp.sources.unix/volume10/screen/
- ngangaga 1y ago[flagged]
- 90s_dev 1y agoNostalgia and novelty are powerful narcotics.
- entropie 1y agoFor 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.
- noosphr 1y agoScreens 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.
- skydhash 1y agoI switched to dtach for the first case.
- kps 1y agodtach for session persistence. “Do one thing well.”
- anthk 1y agoEmacs can work as a daemon.
- noosphr 1y agoIt also has tramp mode which means you can use all your local packages remotely.
- taeric 1y agoWhen 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.
- kstrauser 1y agoIt 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.
- penguin_booze 1y ago> 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?
- wkat4242 1y ago
- DrillShopper 1y agoTry as I might I cannot get my fingers to re-learn the tmux keybindings. The GNU Screen keybindings are that burned into my brain.
- SSLy 1y agoSvP https://github.com/grml/grml-etc-core/blob/master/etc/tmux.conf https://github.com/grml/grml-etc-core/blob/master/etc/tmux.c...
- DrillShopper 1y agoIf the keys and functionality don't work exactly as GNU Screen does then this won't help me. The behavior and keystrokes are so far burned into my brain that it doesn't make sense at this point to learn a new tool unless/until every system I use under the sun doesn't support GNU Screen anymore.
- Cerium 1y agoThankfully you can configure it. I had the same initial difficulty.
- imoverclocked 1y agoThat’s great for your own machine or even common home directory scenarios. The issue is when you have a bunch of machines to manage without chef/puppet/etc or hop onto a random machine or a machine you don’t own etc… defaults are what you get to work with. If screen is there and I need to do something that lasts longer than my ssh session, screen is what I reach for. If it’s non-interactive, I reach for nohup next.
- SEJeff 1y agoIf you don’t care about the output or handle it manually, use detail over nohup, it’s a bit nicer.
- cheema33 1y ago
- dbdoskey 1y agoA similar process is happening with zellij and tmux. Since I switched over I feel that tmux is obsolete.
- lxgr 1y agoWhat 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?
- kstrauser 1y agoA 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.
- eblume 1y agoDefinitely 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 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.
- cozzyd 1y agoScreen is useful when you need to a nest multiplexing inside tmux. And for serial ports
- guappa 1y agoOn my sistems screen doesn't have setuid.
- JdeBP 1y agoIt'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.
- okbitbuddy 1y ago[flagged]
- JdeBP 1y agoPort something like this to OpenBSD and then say that this sort of thing is not hard work. (-: It's very hard work, especially nowadays. The sweet spot was probably in the 1990s, when novices were still likely to know that prime sources of knowledge about this stuff were posts on Usenet, or shell archives of text files written by Daniel J. Bernstein. https://jdebp.uk/FGA/bernstein-on-ttys/ https://jdebp.uk/FGA/bernstein-on-ttys/ I speak from experience of being someone who did my own tweaks to screen in the 1980s, and who has written other similar programs from scratch.
- deleted 1y ago[deleted]
- okbitbuddy 1y ago[flagged]
- deleted 1y ago[deleted]
- UI_at_80x24 1y agoWe usually wait for a version written in Rust for this kind of cruft removal.
- nine_k 1y agoThe 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.
- 1vuio0pswjnm7 1y agoEngineers are rational people. Software developers calling themselves "engineers" are not.
- mardifoufs 1y agoIs it actually in common usage? I'm sure it's used by a lot of people, but it seems quite niche still.
- wkat4242 1y agoIt'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.
- esseph 1y agoSysadmin types, often daily
- wkat4242 1y agoTrue, it's not really as if it's a massive codebase
- esseph 1y agoIDK Man the hammer I use today looks a hell of a lot like the hammer used by engineers throughout human history.
- Henchman21 1y agoI guessed something similar. Screen is from an era where setuid was pretty common!
- fullstop 1y agoI guess I'm glad that I switched to tmux ages ago.
- fzzzy 1y agoscreen has used setuid root for multiuser for at least 20 years. Used to use it in multiuser for remote pair programming.
- icedchai 1y agoI remember installing screen on a SunOS box back in the early 90's. It's been around a longggg time.
- chasil 1y agoIn the EPEL versions of screen, I am seeing the setgid bit set only. I am guessing that later versions setuid to root? $ ll /usr/bin/screen -rwxr-sr-x. 1 root screen 495816 Feb 3 2022 /usr/bin/screen $ rpm -q screen screen-4.8.0-6.el9.x86_64 Edit: Yes, Screen 5.0.0. CVE-2025-46802 can impact earlier releases, but all the other vulnerabilities are for the latest.
- gertrunde 1y agoThe original writeup by the OpenSUSE security team laid this out better: https://security.opensuse.org/2025/05/12/screen-security-issues.html#7-affectedness-matrix https://security.opensuse.org/2025/05/12/screen-security-iss... Different distros built it in different ways, affecting level of vulnerability to the different issues.
- deleted 1y ago[deleted]
- account42 1y agoThis "explanation" only makes it sound worse - why would you even consider setuid if you do not completely understand ever detail of the code base.