Bug 15109

Summary: SOCKDIR default not on /tmp/... - Causes a lot of network traffic.
Product: [Retired] Red Hat Linux Reporter: Eskil Brun <eskil>
Component: screenAssignee: Bill Nottingham <notting>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2000-08-02 12:11:42 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 Eskil Brun 2000-08-02 12:11:40 UTC
The patch screen-3.9.4-notmp.patch that the screen-3.9.5-4 rpm was built
with caused a lot of
network traffic between two fast computers on our network. A user ran
screen on a linux computer
with RedHat 6.2 and his home directory was NFS mounted from a  SunOS 5.6
computer. As SOCKDIR
was on an NFS-mounted directory this caused problems. About 5000 packets
per second of  NFS traffic.

The man page for screen said:

CUSTOMIZATION
       The "socket directory" defaults either to $HOME/.screen or
       simply to /tmp/screens or preferably to /usr/local/screens
       chosen  at  compile-time.  If  screen is installed setuid-
       root, then the administrator should compile screen with an
       adequate  (not NFS mounted) socket directory. If screen is
       not running setuid-root, the user can specify any mode 700
       directory in the environment variable $SCREENDIR.

Given that a lot of people have NFS-mounted home directories I consider the
screen-3.9.4-notmp.patch patch file to be perhaps causing more problems
than it solves.
I cannot see the reason for it being there in the first place? But I would
like to know.

Removing this patch from the source RPM distribution and rebuilding the
package 
solved our problem.

Eskil...
:-)

Comment 1 Bill Nottingham 2000-08-02 16:29:08 UTC
It's *much* simpler from a security standpoint; it avoids
lots of wrangling to allow both root and a user to
use screen at the same time, and it avoids making various
world-writable directories and files in /tmp.