From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux) (KHTML, like Gecko) Description of problem: screen when run for the first time creates the directory /tmp/uscreens. Under that it creates the directory /tmp/uscreens/S-$USER which it uses for storing a named pipe. This does not work well on a multi-user system, the user who first runs screen owns /tmp/uscreens and can change the permissions of it (denying another user access to resume their own sessions), can rename the S-$USER directory from another user (causing them to believe that their session has died which might result in running the same process twice at the same time and corrupting data files), and can probably be used for other attacks too. I believe that a better solution is to do what Gentoo have done. They have the directory /var/run/screen to replace /tmp/uscreen. /var/run/screen is mode 0775 and ownership root:utmp (not sure that group utmp is the most desirable but the screen binary on Gentoo is SETGID utmp to allow screen sessions to be listed in the utmp file). If we don't decide to use this (currently the screen binary is mode 0755 so we aren't using this feature) then we could create a screen group and make it SETGID screen. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Run screen and run "ls -la /tmp/uscreen". Additional info:
Well, the other option is to drop these sockets into ~/.screen, which allegedly breaks with AFS (and possibly NFS) mounted /home... I'm wondering which route to take, i personally prefer ~/.screen... Users can of course set SCREENDIR to override the default. The setgid thing sounds okeyish, too. Even a 777 +t directory owned by root sounds fine unless i'm missing something? (This is just like a /tmp, but dedicated to screen sessions...).
What makes you say that "the other option is to use ~/.screen"? /var/run/screen has been working well on Debian for YEARS. It seems to me that when we discover that our solution to a problem is not optimal then a good algorithm to find a better one is to examine what other distributions are doing. The Debian solution solves all the problems I described in my report, has been well tested in the field (is not likely to cause other problems that we haven't thought of), and is in common use so will give less surprise to administrators who run multiple Linux distributions. Incidentally one issue with ~/.screen that comes to mind is NFS mounted home directories. Sometimes you have one home directory for multiple machines, if you run screen on all those machines then I can't imagine the results being pleasant.
As for the 01777 directory idea, that fails badly in the case of script-kiddy users. Could you imagine running a server with accounts for 1000 first-year CS students in such a manner? You would spend all your time clearing out the files/directories, educating the victims, and larting the idiots.
Well, as you can see, the scheme employed in redhat was in use for years, too, and it doesn't in any way guarantee it's flawlessness... So your logic is a bit off here. Also, you somehow forgot do describe the scheme used in debian. Anyhow, since i use debian, i will just check myself and do whatever debian is doing here. But i would prefer to not be treated as an idiot next time for proposing a different (even if flawed) solution... Blah. (Btw, as for 01777, that's hardly a regression, since current implementation is about the same, just has the additional problem of a semi-random ownership...).
Sorry, in my initial message I referenced Gentoo because I didn't have a Debian system handy for checking. Debian does exactly the same as Gentoo in this regard. Incidentally I think that when the other main distributions are doing something in a certain way we should have a really good reason before considering an alternative. If two options are equivalent in all other ways then the option that is most commonly used (and most expected by administrators) is the better one. You are correct that an 01777 directory is not a regression. It gives the same undesirable behavior as the current situation.
Choosing a utmp group because it happens to be setgid utmp somewhere else doesn't really make sense, especially because it doesn't need to be setgid utmp here. Using a different group is probably best.
Fixed in 4.0.2-9; uses a 'screen' gid.