2

There is daemon in my system, it runs inside of a screen instance and all that is done from an unpriveleged user. I’ve added myself to special sudo group allowing me to run screen from this user, but when I try to use it, e.g.

sudo -u that_user -H /usr/bin/screen -R

I get the subject of this post.

Digging around I found that this message means that screen cannot grab or do output to the pty I actually use when calling it. Common answer to this is to chmod my /dev/pts/N to be rw for the others, but I remember I somehow managed to avoid this earlier. Maybe I missed to save some environment for sudo?

In particular I’m trying to connect to rtorrent daemon running in screen from an ordinary user via sudo, OS is Gentoo amd64. Here is how screen is called from the rc-script:

    start-stop-daemon \
        --start \
        --make-pidfile \
        --pidfile /var/run/rtorrentd.pid \
        --background \
        --user $USER \
        --env HOME="${PWHOME:-/home/$USER}" \
        --name rtorrent \
        --exec /usr/bin/screen -- -D -m -S rtorrentd /usr/bin/rtorrent

Finally worked the actual solution out:

alias rtorrent="urxvt -hold -e /bin/bash -c \"chmod o+rw \\\`tty\\\` && sudo -u rtorrent -H screen -r rtorrentd\""
tijagi
  • 427
  • 2
  • 6
  • 16

2 Answers2

6

Since you are running screen as the special user, the special user needs access to your pty. The only way to accomplish this is to change the permissions on the device.

A better approach is to use screen's multiuser feature, which allow users to connect to another user's screen session without using sudo. This requires setting the screen binary setuid root:

sudo chmod u+s /usr/bin/screen

Then create a new screen session, giving the socket a meaningful name:

screen -S torrent

Inside this screen session, enable multiuser mode and authorise the other users:

^A: multiuser on
^A: acladd tijagi

You should then be able to attach the screen session as yourself:

screen -x that_user/torrent
mgorven
  • 30,615
  • 7
  • 79
  • 122
  • Thanks for the reply, but it doesn’t work for me for some reason. Here is the output: http://pastie.org/pastes/6046281/text But I’m afraid of using screen with root setuid anyway, so I’m thinking about to run screen for rtorrent in a special urxvt window which will change its permissions on the fly. – tijagi Feb 04 '13 at 20:12
  • @tijagi Did you start a new named screen session with `screen -S rtorrentd`? – mgorven Feb 04 '13 at 20:47
  • Look at the my first post, I’ve expanded it. – tijagi Feb 04 '13 at 21:07
  • @tijagi That all looks fine, I'm not sure why it's not working. – mgorven Feb 05 '13 at 00:39
  • Is it possible to enable this via **.screenrc**? – earthmeLon Apr 12 '13 at 18:23
  • @earthmeLon The `multiuser` and `acladd` commands can be added to `.screenrc`. – mgorven Apr 12 '13 at 18:45
1

The ownership of the terminal device is not changed when using sudo, but changing its permissions is actually not the only solution (not a great solution though, because it opens a security hole).

The common approach is to start a "script" session (but don't save the output, send it to the trash), which works because it uses another terminal device.

sudo -su USER script -c bash /dev/null
# new terminal with sufficient permissions for screen
screen -R

Or all in one command, e.g., as alias in your .bashrc:

alias user-screen-attach='sudo -su USER script -c "screen -x" /dev/null'
basic6
  • 353
  • 3
  • 9