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: Cannot open your terminal '/dev/pts/0'
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.
Try running
script /dev/null
as the user yousu
to before launching screen - its a ghetto little hack, but it should make screen happy.I am using a wrapper function around
screen
for the user(s) that Isudo su
to. This is the wrapper function that I've added to the user(s)~/.bashrc
: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.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
Assuming we're talking about this error:
Here's a one-liner (could be used as "alias gobob", for example):
Explanation:
This will start a shell (like login shell) as user bob. User bob starts
script
, which is told to invoke a bash (could be dash or ksh...) and a copy of the session is thrown away.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.
You say you do:
I'm wondering about the trailing dash. I usually do:
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.
I would just give the read/write permission to "other":
Then try
screen
againI 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.