That's a limitation on how screen functions (i.e., it needs to have ownership of the terminal, which only the actual login process grants); sudo cannot circumvent this as it does not alter tty permissions.

While it's a little annoying, the workaround you describe provides full functionality during interactive sessions (and it bears reminding here that tools should not be running interactive processes in detached screen sessions in any case).

I don't remember the Toolserver having this issue. This doesn't seem like a wontfix to me. This is pretty awful behavior currently. Surely we can do better.

local-dbreps@tools-login:~$ screen
Cannot open your terminal '/dev/pts/50' - please check.

I kept getting this. I checked https://wikitech.wikimedia.org/wiki/Screen to no avail. On IRC, I was told (by a bot, no less) that running "script /dev/null" is a workaround. It seems Roan found another workaround.

At a minimum, this needs to be documented (which I'll do momentarily) and the error message could be hacked to be clearer what the hell is happening ("check /dev/pts/50" is pretty much an online equivalent of "go fuck yourself"). Re-opening this for further thought and consideration.

Then you almost certainly* remember incorrectly. Screen can only operate on the terminal you are connected to (obviously), and that is necessarily owned by the user you have logged in with.

Chances are this scenario (start a screen session /after/ having switched to another user) would have been less common on toolserver since most people ran only as their login user except for the infrequent multi-maintainer project -- which all projects are in Tool Labs.

• (I say almost here because it /is/ possible to set screen suid to root; but that's on the same list as "chmod 777 your home", "set your password to '1234'", or "allow telnet" -- something a user might find convenient but a sysadmin should be fired for).

According to https://wiki.toolserver.org/view/Multi-maintainer_projects#Using_screen, it is possible on the Linux hosts, but not on the Solaris hosts. I just confirmed: dbreps@willow.toolserver.org (Solaris) gets the same error as above while dbreps@nightshade.toolserver.org (Linux) has no issue starting screen.

The Toolserver folks had a workaround for Solaris hosts (using ttyallow), but now we've reached a new question: what did the Toolserver do on its Linux hosts to resolve this issue that Labs hasn't done?

I can't tell; I don't have a MMP on the toolserver, and a cursory inspection of nightshade shows that screen isn't suid to root, which means that it should not be possible for it to open the tty when invoked from a sudo-ed user:

crw--w---- 1 marc tty 136, 31 Sep 5 04:39 /dev/pts/31

Whereas:

-rwxr-sr-x 1 root utmp 364088 Jul 29 2009 /usr/bin/screen

meaning that screen runs with the privileges of the invoking user, who would not have permission to open the terminal. Can you switch to an MMP account and do a "ls -l tty" to see if something funky is going on with the terminal's permissions? That might give me a hint.

The hack with script is exactly that -- a hack: it creates a new shell, a new terminal pair, and has a process running busy shuffling the data between both sides of the pipe, with a copy to /dev/null. At best, it is horribly wasteful and doubles context switches.

Oh! I figured out how they do it: they have turned on log_input, log_output or both in their sudo configuration -- this causes the creation of a pty (like script does), and thus neatly circumvents the problem; the tty of the sudo-ed user is brand new and owned by the user.

... at the cost of, you know, logging all the input and output of your session.

Needless to say, that will not happen in Tool Labs -- even having the capability to replay users' sessions (including passwords typed and all!) would be a *massive* violation of privacy.

I'm forced to wonder whether users of toolserver are aware that their sessions are logged in this way.

(In reply to comment #6)

... at the cost of, you know, logging all the input and output of your
session.

Needless to say, that will not happen in Tool Labs -- even having the
capability to replay users' sessions (including passwords typed and all!)
would be a *massive* violation of privacy.

Would it? What's the difference between this and .bash_history?

Is the logged input/output available to all users or only to roots (and the session owner)?

.bash_history records the commands you typed at the shell prompt that were actually submitted; recording the stream would include everything sent and/or received, including keystrokes to applications, typed passwords, etc. For instance, if you mistakenly start to type a password in your ssh session because your focus was on the wrong window then backspace over it, .bash_history would not record it, log_input and log_output would.

Another difference is that you can manage (delete, edit, verify) your .bash_history, whereas logged I/O is neither visible nor under your control.

The logged I/O would only be available to roots; but much of that is stuff that I wouldn't want to exist on disk even granted perfect trust in everyone involved. An accident that leaves /var/log/sudo-io/ accessible or a security flaw that allows escalation would expose that data -- on the instance or even the host.

Key recording is just too much of an exposure, especially since the only putative benefit is the very marginal convenience of being able to start a screen session after sudo rather than just before it.

That will not be changed from the current method; automatically logging I/O is an unacceptable security risk, especially if it happens unconditionally and without the user's knowledge/consent.

Run screen from your own user, or use screen to created a tty for the task.

valhallasw@tools-login:~$ chown valhallasw:tools.tsreports /dev/pts/164
valhallasw@tools-login:~$ chmod g+r /dev/pts/164
valhallasw@tools-login:~$ become tsreports
tools.tsreports@tools-login:~$ screen

This works for me. I suppose there still is some security impact with this (I guess all tsreports users can now read my TTY? but that might already be possible when I 'become tsreports'?) but it's somewhat less extreme.

Alternatively, could log_input be used to redirect to /dev/null, thus mitigating the risk of log files?