Arvados

IMO login links should only be considered duplicates when head, tail, and login name are equal.

It does make sense to give an Arvados user permission to log in to two different Unix accounts on the same VM (e.g., "alice", "bob", and "root") and in the screenshot here the workbench1 UI is attempting to show this sensibly.

We could prohibit this and tell admins "choose one account per person and tell them to use a more cumbersome solution like sudo, or key-forwarding/tunnels + manually managed authorized_keys, to get into other accounts" and it would still be possible for them to make things work ... but I don't see why we should enforce this sort of cruelty, given that we've already built the infrastructure to support many-to-many permissions.

Tom Clegg wrote:

IMO login links should only be considered duplicates when head, tail, and login name are equal.

Definitely in that case, and that is the case I'm the most concerned about. To have a different login name is something you really have to go out of your way for in workbench (you would have to manually go edit the can_login link after you create it).

It does make sense to give an Arvados user permission to log in to two different Unix accounts on the same VM (e.g., "alice", "bob", and "root") and in the screenshot here the workbench1 UI is attempting to show this sensibly.

I think we can disagree on that a bit, the UX is confusing in the screenshot. At the very least there's a missing newline between the two ssh commands.

We could prohibit this and tell admins "choose one account per person and tell them to use a more cumbersome solution like sudo, or key-forwarding/tunnels + manually managed authorized_keys, to get into other accounts" and it would still be possible for them to make things work ... but I don't see why we should enforce this sort of cruelty, given that we've already built the infrastructure to support many-to-many permissions.

For the record, workbench(2) does not support editing the login name when creating a login link for a user, so that part of the infrastructure we don't have. You can work around it by updating the user record after creating one login link, or by creating 2 identical links and then editing the property field for one of the can_login links.

But... I don't know why you'd ever want to have two accounts with separate login names for a user. What is the use case for that? We don't use that anywhere. If you want to give a user access to root-level powers, you add them to the sudo group. You don't create a second account for them, why would you do that?

Anyway; if we just make sure that links with identical head/tail and login name are not allowed, that's good enough for me. Having links with multiple login names for a user can remain a feature that is technically possible but in practice unused.

Ward Vandewege wrote:

I think we can disagree on that a bit, the UX is confusing in the screenshot. At the very least there's a missing newline between the two ssh commands.

Yes, that's what I meant by "the UI is attempting to show this sensibly."

But... I don't know why you'd ever want to have two accounts with separate login names for a user. What is the use case for that? We don't use that anywhere. If you want to give a user access to root-level powers, you add them to the sudo group. You don't create a second account for them, why would you do that?

Some people prefer allowing "ssh root@host" (or "ssh another-persons-account@host") directly, rather than relying entirely on sudo, so things like scp and rsync work easily.

Personally, I dislike sudo because either it asks for a password, in which case I need to type/paste a password, which sucks and/or can't be scripted, or it doesn't, in which case some program (like npm) will eventually invoke it without warning or asking me first and do undesired things as root, which also sucks.