Bug 98320 - Screen's socket directory inherits stickybit
Screen's socket directory inherits stickybit
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lon Hohberger
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-06-30 20:13 EDT by Ben Woodard
Modified: 2007-04-18 12:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-07-10 15:56:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ben Woodard 2003-06-30 20:13:51 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/

Hey Ben,

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
than /tmp?

  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?


-Mike Miller

Version-Release number of selected component (if applicable):

How reproducible:

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.

Additional info:
Comment 1 Ben Woodard 2003-06-30 21:28:45 EDT
From: 	Ryan Braby <braby1@llnl.gov>
To: 	Ben Woodard <bwoodard@llnl.gov>
Cc: 	Michael J. Miller Jr. <miller87@llnl.gov>, woodard9@llnl.gov
Subject: 	Re: Bug Report (screen)
Date: 	Mon, 30 Jun 2003 17:43:06 -0700	
Hi Ben,

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.

Comment 2 Ben Woodard 2003-06-30 21:29:27 EDT
 * 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).
#undef SOCKDIR
Comment 3 Lon Hohberger 2003-07-01 10:23:05 EDT
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
Comment 4 Lon Hohberger 2003-07-01 18:28:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.