Bug 150392

Summary:	/tmp/uscreens is a bad idea
Product:	[Fedora] Fedora	Reporter:	Russell Coker <rcoker>
Component:	screen	Assignee:	Petr Rockai <prockai>
Status:	CLOSED RAWHIDE	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	4.0.2-9	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-27 18:45:32 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Russell Coker 2005-03-05 12:44:18 UTC

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:

Comment 1 Petr Rockai 2005-03-22 08:19:17 UTC

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...).

Comment 2 Russell Coker 2005-03-22 14:13:10 UTC

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.

Comment 3 Russell Coker 2005-03-22 14:15:56 UTC

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.

Comment 4 Petr Rockai 2005-03-22 14:33:33 UTC

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...).

Comment 5 Russell Coker 2005-03-22 14:48:04 UTC

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.

Comment 6 Bill Nottingham 2005-05-27 16:36:21 UTC

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.

Comment 7 Bill Nottingham 2005-05-27 18:45:32 UTC

Fixed in 4.0.2-9; uses a 'screen' gid.