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

 
 

bug #25214: screen does not work in sudo

Submitted by:  None
Submitted on:  Tue 30 Dec 2008 10:12:16 PM UTC  
 
Category: Program LogicSeverity: 3 - Normal
Priority: 5 - NormalStatus: Need Investigation
Privacy: PublicAssigned to: None
Open/Closed: OpenRelease: 4.0.3
Fixed Release: NonePlanned Release: Later
Work Required: 1 - Days

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 15 Jan 2009 10:45:48 PM UTCmicahcowanStatusNone=>Need Investigation
      Planned ReleaseNone=>Later
      Work RequiredNone=>1 - Days

    Back to the top


    Powered by Savane 3.1-cleanup1