bugGNU Screen - Bugs: bug #25214, screen does not work in sudo

 
 

bug #25214: screen does not work in sudo

Submitter:  None
Submitted:  Tue 30 Dec 2008 10:12:16 PM UTC
   
 
Category:  Program Logic Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Need Investigation
Privacy:  Public Assigned to:  None
Open/Closed:  Open Release:  4.0.3
Fixed Release:  None Planned Release:  Later
Work Required:  1 - Days
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 08 Jun 2010 09:19:02 AM UTC, comment #2: 

I noticed that screen needs write access as the new user to the tty of the user doing sudo. For example:

$ chmod 666 $(tty)
$ sudo su - <other-user> -c screen

This works, but screen does not react to size changes of the xterm in which I am doing all this :-(

Any ideas on how to get screen pick up changed xterm sizes?

PS: I know that sudo su is a kludge, not my choice :-(

Schlomo Schapiro <sschapiro>
Fri 06 Mar 2009 12:07:50 AM UTC, comment #1: 

This subject came up independantly on the Linux on 390 Port <LINUX-390@VM.MARIST.EDU> list, in this thread:
 Re: Which user env. variable tell me that it is in  "su - "   mode ?

Ivan opines that, "And my observation is that "screen" is attempting at some point to re-open the process controlling terminal file node in order to ensure any redirection does not affect front-end 'screen' operations...."

John wonders, "why it does that, rather than check (with isatty(), fstat() or ttyname()), then belch if it doesn't like what it sees?"

I can imagine that this might be bad:
echo stuff | screen

Depending on circumstances of its creation, ttys on Linux have permissions 0600 or 0620, and are owned by group tty. When root switches to a regular user's account using su or sudo, that oser cannot open new read (and often write)  handles to the inherited tty.


Anonymous
Tue 30 Dec 2008 10:12:16 PM UTC, original submission:  


I noticed that the screen version supplied with Debian etch (package version 4.0.3-0.3+b1, does not seem to be too different from upstream 4.0.3) does not work in sudo: it panics with message "Cannot open your terminal '/dev/pts/42' - please check."

The reason (as far as I can discern) is that screen learns the name of the pty it runs on using ttyname() on stdin, and then it tries to open it that pty with secopen(). Problem is, when using sudo, the pty it is connected to is not owned by the user screen run as (the owner is the user that ran sudo).

Is there a reason to open() that pty again? Why are the already-open file descriptors inadequate?

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sschapiro (Posted a comment)
  • -email is unavailable- added by micahcowan (Updated the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-01-15 micahcowan StatusNone Need Investigation
        Planned ReleaseNone Later
        Work RequiredNone 1 - Days

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code