Red Hat Bugzilla – Bug 150392
/tmp/uscreens is a bad idea
Last modified: 2007-11-30 17:11:01 EST
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):
Steps to Reproduce:
Run screen and run "ls -la /tmp/uscreen".
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
As for the 01777 directory idea, that fails badly in the case of script-kiddy
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
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
Using a different group is probably best.
Fixed in 4.0.2-9; uses a 'screen' gid.