Red Hat Bugzilla – Bug 98320
Screen's socket directory inherits stickybit
Last modified: 2007-04-18 12:55:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
Here is a bug report that I received from a SA at LLNL. He seems to have found a
problem with the way that we compile screen that creates a problem for screen
users on multiuser systems.
I confirmed that the problem does exist with RH9's version of screen.
Basically the problem is that screen creates a directory /tmp/uscreen/S-username
when it is run. The first user that runs screen creates /tmp/uscreen and because
it is in /tmp it inherits the stickybit and gets created such that no one else
can write to that directory.
185 [ben@xenophanes Personal]$ ls -ld /tmp/uscreens/
drwxrwxrwt 3 ben ben 1024 Jun 12 07:01 /tmp/uscreens/
We've found what appears to be a bug in the screen rpm...
Here are the details from the ticket I got...
06/26/03 16:09:34 barbara
The "man screen" indicates that whether the "socket directory" uses
$HOME/.screen or /tmp/screens or /usr/local/screens is an option choosen at
compile time. Perhaps this should be recompiled and changed to use $HOME rather
When I tested, I found that after I exit "screens," it doesn't remove the
/tmp/uscreens directory, and then this directory prevents others from using it.
It does create subdirectories in /tmp/uscreens, with one directory per user with
appropriate access privileges.
So I'm wondering if the sys admin should recompile screens to have it use
$HOME instead of /var/tmp? Or should a /tmp/uscreens be created by root with
global rwx permissions and exempt it from purging?
Jose likes it and he would like to use it. Another user told Jose about it,
and this other user uses it quite a bit. However if there are security reasons
to remove it, certainly it should be removed.
I see today on ilx2, there is still the directory /tmp/uscreens that was
created on Jun 4, owned by user dflowers, which prohibits others from using this
tool on this machine. Would it not be better to have root create a globally
write/read/execute directory for this so one user running screens doesn't stop
all other users using it?
What do you think? When I used it many years back it created the socket
directory in $HOME/.screen
Do you know why RedHat didn't compile it that way?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. create a box with two normal (non-root) users
2. run screen as user 1
3. run screen as user 2
Actual Results: user 2 can't run screen
Expected Results: both users could run screen.
From: Ryan Braby <email@example.com>
To: Ben Woodard <firstname.lastname@example.org>
Cc: Michael J. Miller Jr. <email@example.com>, firstname.lastname@example.org
Subject: Re: Bug Report (screen)
Date: Mon, 30 Jun 2003 17:43:06 -0700
I took a look at the bugzilla report, and think it should be mentioned
that as well as having screen work for multiple users, we would also
prefer it to operate in a mode that does not require directories or
files to have global read/write permissions. Thus, why Mike mentioned
possibly using $HOME/.screen/. Of course, another option would be to
have it use $TMPDIR/uscreens/ (we set $TMPDIR to include the userid for
users) or something along those lines.
* Define SOCKDIR to be the directory to contain the named sockets
* screen creates. This should be in a common subdirectory, such as
* /usr/local or /tmp. It makes things a little more secure if you
* choose a directory which is not writable by everyone or where the
* "sticky" bit is on, but this isn't required.
* If SOCKDIR is not defined screen will put the named sockets in
* the user's home directory. Notice that this can cause you problems
* if some user's HOME directories are AFS- or NFS-mounted. Especially
* AFS is unlikely to support named sockets.
* Screen will name the subdirectories "S-$USER" (e.g /tmp/S-davison).
Oddly enough, I see a changelog from 1999 by one of our engineers which claims
to have done exactly what I am doing. I wonder where that functionality went...
I'm disabling the global screen-session directory; screen will use $HOME/.screen
Correction... screen will do the following:
- Try to open a UNIX domain socket in $HOME/.screen/<socket>
- If successful, it will use $HOME/.screen as the socket directory.
- If unsuccessful, it will use /tmp/screen-<user>
This is the middle path: /tmp/screens isn't created by a specific user's screen
process, and in most cases (ie, whenever $HOME/.screen is a directory on any
file system which supports UNIX domain sockets), we use that - making it more
secure in most cases. For instance, old versions of NFS do not support sockets,
nor does AFS. We also don't need to worry about /tmp/screens getting removed
periodically (thus needing to be re-created).
That should do it.