Bug 15109 - SOCKDIR default not on /tmp/... - Causes a lot of network traffic.
SOCKDIR default not on /tmp/... - Causes a lot of network traffic.
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: screen (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-02 08:11 EDT by Eskil Brun
Modified: 2014-03-16 22:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-02 08:11:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eskil Brun 2000-08-02 08:11:40 EDT
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 12:29:08 EDT
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.

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