Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Found out today that running screen as a different user that I sudo into won't work!

i.e.

ssh bob@server         # ssh into server as bob
sudo su "monitor" -

screen (fails)

I have a script that runs as the "monitor" user. We run it in a screen session in order to see output on the screen. The problem is, we have a number of user who logs in with their own account (i.e. bob, james, susie, etc...) and then they sudo into the "monitor" user. Giving them access to the "monitor" user is out of the question.

share|improve this question
4  
Is this the error that you are getting? "Cannot open your terminal '/dev/pts/0' - please check." –  Jim Feb 25 '10 at 15:26
    
yep thats the one. I understand why it's happening but is there a workaround? –  luckytaxi Feb 25 '10 at 15:32
4  
A comment on your commands -- I keep seeing people running sudo su "user" -. Why not use sudo -u user -s? –  Andrew Aylett Feb 25 '10 at 16:38
    
@Jim: +1 for supplying the missing error message. –  Dennis Williamson Feb 25 '10 at 16:41
    
@Andrew Most guys I know do sudo su - I think it's just what people get used to (in my case it's because you don't need to know any sudo flags to sudo su - I don't think I've ever read the sudo manpage :) –  voretaq7 Feb 25 '10 at 16:50

6 Answers 6

up vote 62 down vote accepted

Try running script /dev/null as the user you su to before launching screen - its a ghetto little hack, but it should make screen happy.

share|improve this answer
    
so um ... any security implications with this one? I think I can add the user to the tty group but that wouldn't be ideal. :-P –  luckytaxi Feb 25 '10 at 19:07
2  
Re: security implications, none I'm aware of (but that doesn't mean there aren't any :) - IIRC this relies on a side-effect of "script" opening a new terminal device (as the user invoking it), and since you're sending script's output to /dev/null there's nothing to capture. It's also definitely safer than adding users to the tty group (IMHO) –  voretaq7 Feb 25 '10 at 19:20
    
This suggestion doesn't work (not on Ubuntu 11.04 anyway). By default, a user Joe's tty has permissions crw--w---- and is owned by user Joe, group tty. If Joe tries sudo -u bill screen, it fails (Cannot open your terminal) because user bill doesn't have permission to Joe's tty. If Joe runs script /dev/null, the new tty has the same ownership and permissions as the first one, so a sudo -u bill screen still fails. –  Mox Aug 19 '11 at 20:43
1  
@nalply Frankly you shouldn't find multiple shells confusing if you're a Unix system administrator -- that said, script can be used to launch screen. Then you only have to exit twice (once for screen, once for su). (This is something the script man page can clarify for you, if you take the time to read it...) –  voretaq7 Oct 8 '13 at 15:40
2  
Or just run sudo -u bob script -q -c 'screen -dr myscreen' /dev/null. Then you only have one terminal to exit/detach from. –  Andy Shulman Nov 27 '13 at 4:48

I am using a wrapper function around screen for the user(s) that I sudo su to. This is the wrapper function that I've added to the user(s) ~/.bashrc:

function screen() {
  /usr/bin/script -q -c "/usr/bin/screen ${*}" /dev/null
}

This allows me to use all of the options and parameters for screen that I might want to use. I am contemplating on putting this function systemwide.

share|improve this answer

I just hit this problem. Solved it with chmod +rw $(tty) before running sudo. The problem with this solution is that anyone can connect and snoop on your terminal after that.

share|improve this answer
    
Sounds like a great solution. –  Evan Carroll Jan 20 '12 at 16:19
1  
@EvanCarroll It's a great solution, except the part where it gives the entire world read & write access to his terminal. Just a minor security problem - No program would care about that, except of course anything that checks terminal security before accepting passwords (gpg for example). And surely he'll never be on a system with malicious users who would watch the tty and sniff passwords... –  voretaq7 Oct 8 '13 at 15:35

You say you do:

sudo su "monitor" -

I'm wondering about the trailing dash. I usually do:

sudo su - username

The dash (per the su man page) tells su to "make the shell a login shell". This means it will source all the usual shell startup scripts and set things like PATH and HOME properly.

share|improve this answer
    
Nope. sudo su - username and sudo su username - do the same thing. –  Tim Ludwinski Nov 10 at 20:59

Assuming they are SSHing into the host anyway, you could add the public ssh keys for each user that needs access to the monitor account in the ~monitor/.ssh/authorized_keys file. Then on each user's remote machine they can run

ssh -t monitor@remote.machine screen -RD

share|improve this answer
    
This is another good approach -- You would have to specify forced commands in the authorized keys file though (per luckytaxi's "giving them access to the 'monitor' user is out of the question" note above -- forced commands could limit them to just attaching the screen session) –  voretaq7 Feb 25 '10 at 16:59
1  
I wasn't sure how to address that in my answer, because he said "giving them access...is out of the question", but also said "...they sudo into the 'monitor' user". But I agree, forcing command restriction in the authorized_keys should take care of that. –  Alex Feb 25 '10 at 20:14

Probably would have to change permissions on the device in question or add monitor to a group that has permission to read that device, that would be my first inclination. But you'd have to weigh the security implications of doing so.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.