Bug 98312 - screen fail attempting to reopen tty
Summary: screen fail attempting to reopen tty
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: screen
Version: 9
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Lon Hohberger
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-06-30 22:15 UTC by Kasper Dupont
Modified: 2007-04-18 16:55 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-07-01 14:05:19 UTC
Embargoed:


Attachments (Terms of Use)

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.




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