Okay, sharing a screen with screen is possible, but hairier than I thought.
- It requires
screen to be setuid to root, so it can access the
sockets of other users. (One might think this could be made to work
with just setgid, but I didn't check if screen can be compiled
that way.)
- The documentation for the multiuser commands is a bit on the light side, which means that configuring it isn't that simple. Also, while you can set ACLs for other users, there doesn't seem to exist an option for printing the current ACLs.
That said, I was able to get it to work, for some values of "work".
First, make sure it has enough privilege, and fix the permissions on /var/run/screen:
chmod u+s /usr/bin/screen
chmod 755 /var/run/screen
Then, bundle some configuration commands in a file:
$ cat shared.screen.rc
multiuser on
aclumask ?-wx
aclumask ??-wx
addacl foo
aclchg foo -x ?
aclchg foo +x detach,help,next,prev,windows,info,select
multiuser enables multiuser mode, aclumask limits the default access for all users, then addacl allows (all) access to user foo. The aclchg commands remove execute (-x) access to all commands (?), and we then allow some benign commands again.
Then, then running screen -c shared.screen.rc, creates a screen the user foo can attach to:
foo$ screen -ls bar/
There is a suitable screen on:
18839.pts-2.test (08/21/16 22:09:07) (Multi, detached)
foo$ screen -r bar/
Writing to the screen and using most commands result in an error. However, copy mode seems to work. Also, starting screen with screen -rd bar/ as the non-owning user kicks the owning user out, even though you'd imagine that shouldn't be possible. screen -RRD works too, and logouts the original user. Even though you can disallow pow_detach and detach (which should be fun for the second user), it doesn't seem to affect this. Amusing.
Of course, if you don't mind, and are happy to let other users mess with your screen, using multiuser on and addacl foo should be enough. Not that I'm saying you should.