Bug 98312

Summary: screen fail attempting to reopen tty
Product: [Retired] Red Hat Linux Reporter: Kasper Dupont <bugzilla>
Component: screenAssignee: Lon Hohberger <lhh>
Status: CLOSED NOTABUG QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-07-01 14:05:19 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 Kasper Dupont 2003-06-30 22:15:25 UTC
Description of problem:
screen try to open the current tty, this is not always possible.

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

How reproducible:
Always

Steps to Reproduce:
1. Log in as user1
2. Use su to switch to user2
3. start screen
    
Actual results:
An error message apears (terminal name may differ):
Cannot open your terminal '/dev/pts/3' - please check.

Expected results:
screen starts and works as if user2 had logged in
directly.

Additional info:
There is no problem in the case when using su to switch
to the root user. There is only a problem if user2 is
not root. screen should be able to work by using an
already open file descriptor or /dev/tty.

Comment 1 Lon Hohberger 2003-07-01 14:05:19 UTC
A user's terminal device is not readable/writeable by other users by default; to
do otherwise would pose quite a security problem.  Root does not have this
limitation (because root can read/write anything).  I DO NOT recommend this, but
if you *really* want another user to be able to open your tty (using 'su' is,
for all intensive purposes, the same as another user):

   chmod 666 /dev/pts/2

The reason 'su' doesn't have this problem is because it doesn't open a new TTY.
 It merely spawns a new shell and pipes input/output from the child session to
the parent TTY - which is why 'su' does not need to change the TTY's ownership
or permissions.  (Again, changing TTY ownerships and permissions is generally
*bad*.)  

Applications, such as screen, which require direct access to the controlling
terminal must have read/write access as the _current_ UID.

Another way to do it would be to simply SSH in as the user you intend to run
screen as, or alternatively run screen and then run 'su' within the screen sessions.