Tell me more ×
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 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
3  
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

5 Answers

up vote 25 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
@mox - Clarified in my answer when to run screen (you run it as the user you suing to - "bill" in this case, and it creates a new tty device owned by "bill") -- Definitely needed clarifying as it took me a second to remember that. – voretaq7 Aug 19 '11 at 21:05
Works perfectly in Ubuntu 12.10. – Hengjie Mar 4 at 22:40

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

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

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

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.