multi-user access to cereal sessions

[jrollins]

Multiple separate users should be able to access a single cereal session. There should also be some record of who attaches and when.

[dkg]

wouldn't using screen -x instead of screen -r do that sufficiently?

If we're allowing users to connect via ssh through ~/.ssh/authorized_keys isn't sshd capable of logging who makes the connections (by recording the fingerprint of the connecting key)?

[dkg]

On Fri 2007-05-11 11:38:15 -0400, Jamie McClelland wrote:

I think it would be creepy to connect to a screen session that someone else is
already connected to without having some warning. In an ideal situation, I
think cereal should say: there's already connection, do you want to join them?
And, the user already connected would get some notification that someone is
joining the screen session. Have no idea if what I'm asking for is relatively
easy or very difficult, but in terms of user interface, seems to make sense.

This seems pretty reasonable to me. i don't know how hard it would be for implementation. maybe the screen caption (the modeline-y sort of thing) can report the number of connected users?

[jrollins]

I question whether we should allow multiple users to connect to a single session at the same time. I don't think it's a particularly good idea, and I would at the very least want to be able to disable that ability. I don't think we should spend extra work allowing that ability. It's always a bit tricky to manage a single multi-user screen session.

I was under the impression that this ticket was just about allowing multiple users to access a screen session in a single-user manner (ie. not simultaneously), something more akin to specifying a group as owner as opposed to just a single user.

[dkg]

well, we can already rely on ssh authorized_keys to enable multiple people to access.

sometimes having two people connect to a session is a good thing, though perhaps it's a better idea to have subsequent connections just "follow" instead of "attach"

[jrollins]

I mean that I don't think it's a good idea for two people to have *control* of a session simultaneously. there's really no reason for that. the ability to have arbitrary number of people follow a session is already built in, so i don't think that's an issue.

[dkg]

What if you want to take turns controlling a session? is there a way that we can make it easy/seamless to hand off "attachment", while other users "follow"?

I'm pushing on this because my experience of shared control of a session/console is actually very positive. People learn from each other a lot, and feel more engaged when control can be shared. Having an explicit "who's driving" switch would be a nice thing, though.

[jrollins]

I just don't see this as being necessary. I think the ability of other to follow while someone is attached is sufficient. I won't oppose this feature, though, as long as there is a way to enable it on a session-by-session basis.

[jrollins]

I just verified that cereal can run fine in another screen session. I think that this is a more than adequate solution to dkg's desire to have multiple users access a session simultaneously. Here's my prescription for how this would be done:

• Users that need simultaneous access to the same session can be given ssh access to the cereal session owner
• The first user logs on a starts a screen session. Be sure that this screen session uses a different escape sequence than is used by the cereal session.
• The second user logs in and runs "screen -x". This will fail because the specific screen session to attach to was not specified because of all of the available cereal session. Find the non-cereal session in the list and attach to that one specifically.
• Attach to the desired cereal session with "cereal a ...". Now the 2 users have simultaneous access to the same cereal session.

Does this satisfy your requirement, dkg? I'm not exactly sure how this would work with cereal-session, though.

This does not deal with the issue of how to have different system users have non-simultaneous access to the same session.

[dkg]

Replying to jrollins:

I just verified that cereal can run fine in another screen session. I think that this is a more than adequate solution to dkg's desire to have multiple users access a session simultaneously.

I think this is an adequate solution, but not more than adequate because it is inconvenient and clumsy. I would like to see this use case be more convenient and less clumsy.

Does this satisfy your requirement, dkg? I'm not exactly sure how this would work with cereal-session, though.

by "cereal-session" do you mean /usr/bin/cereal-shell (or whatever form that proposal takes)? I'm not sure how it interacts with that either: a properly-limited cereal-shell may well require a more sophisticated multi-user access approach if we want to be able to constrain the user account cleanly.

[dkg]

Given our experience at the ​virtualization hackday, i think it's important that we make it easy for multiple users to attach simply. Making the screen attachment with -x instead of -r is such a simple change that seems to be worth it to me.

As you point out, it's already possible for there to be simultaneous control, so why not allow it directly within cereal?

[jrollins]

to be clear, by "multiple users" we're really talking about 2 unique individual people who have login access to the same user account that controls the cereal session of interest. There are two things we could be talking about, so lets be clear:

a) users 'foo' and 'bar' exist on host 'scs'. cereal session 'monkey' exists on 'scs'. users 'foo' and 'bar' can attach to cereal session 'monkey' at the same time.

b) user 'foo' exists on host 'scs'. cereal session 'monkey' exists on 'scs'. users 'baz@remotehost1' and 'qux@remotehost2' both have ssh access to user 'foo@scs', so that they can both log into 'foo@scs' at the same time and attach to the same cereal session at the same time.

I am assuming that we're talking about the latter: case b. If so, then I think changing the 'screen -r' to a 'screen -x" in the in /usr/bin/cereal attach function will is all that is needed to allow that to happen. I still think that it should be sufficient that one user can attach and others can follow. However, since we don't seem to have a way to *prevent* the same user from attaching to a given serial session with 'screen -x', then maybe we should just go ahead and add that functionality. My big concern is about logging. I'm not sure how to properly log that another user is attaching, and to log who that other user ultimately is. There's going to have to be a little bit of experimentation with this.

Case a is probably more difficult to implement, but it is probably possible, and may be worth looking into since it could potentially provide better logging of who is doing what.

in either case, i think there are issues that need to be considered beyond just changing an 'r' to an 'x'.

[jrollins]

Maybe case a above can be accomplished with the screen acl's.

[dkg]

Yes, i agree that there are more sophisticated cases to consider, but handling case "b" with screen -x instead of screen -r seems like the right thing to me.

i'm not sure that screen acl's will work without screen itself being setuid (which it is not in debian, for reasonable security concerns).

I see what you're saying about logging, though. we should experiment with that.

[dkg]

FWIW, if we add a %f to the caption line someplace, it will result in (L) when only one client is attached to the screen window, and a &(L) when more than one client is attached. (i just tested this, and it's true for the use case where two instances of a single local user accounts connects to a screen session).

While the & appears immediately upon the second user attaching, it doesn't go away immediately upon detaching. it appears to wait until the minute changes on the clock or something before cleaning up its state. I don't think this is too bad to accept, given that some detachments are due to network errors and you really don't know for a little while whether the scenario is recoverable or not.

the %u option is more appealing in that it is supposed to print out the names of the other users attached, but this doesn't provide any distinction if there are two instances of the same user account connected (the common scenario for cereal at the moment).

I've also improved the logging by including the pty of the attaching and detaching users here.

So i think this is closed in [943]. Feel free to re-open if there are more outstanding concerns.