Bug #19057
closed[controller] should not allow adding the same user+login to a VM more than one time
Added by Ward Vandewege over 2 years ago. Updated over 1 year ago.
Description
As observed in #19049, it is currently possible to attach the same user to a VM multiple times, which does not make sense and should not be allowed.
The link has the same head and tail uuid, so presumably we could filter out duplicates in controller and return an error.
Files
20220426-virtual-machine-duplicate-link.png (26.2 KB) 20220426-virtual-machine-duplicate-link.png | Ward Vandewege, 04/26/2022 08:00 PM |
Related issues
Updated by Ward Vandewege over 2 years ago
- Related to Bug #19049: VM admin interface rough edges added
Updated by Ward Vandewege over 2 years ago
- Description updated (diff)
- File 20220426-virtual-machine-duplicate-link.png 20220426-virtual-machine-duplicate-link.png added
Updated by Tom Clegg over 2 years ago
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.
Updated by Peter Amstutz over 2 years ago
- Target version changed from 2022-05-11 sprint to 2022-05-25 sprint
Updated by Ward Vandewege over 2 years ago
- Related to Idea #18693: Deduplicate permission links added
Updated by Ward Vandewege over 2 years ago
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.
Updated by Tom Clegg over 2 years ago
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.
Updated by Peter Amstutz over 2 years ago
- Target version changed from 2022-05-25 sprint to 2022-06-08 sprint
Updated by Peter Amstutz over 2 years ago
- Target version changed from 2022-06-08 sprint to 2022-06-22 Sprint
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-06-22 Sprint to 2022-07-06
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-07-06 to 2022-07-20
Updated by Tom Clegg about 2 years ago
- Subject changed from [controller] should not allow adding the same user to a VM more than one time to [controller] should not allow adding the same user+login to a VM more than one time
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-07-20 to 2022-08-03 Sprint
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-08-03 Sprint to 2022-08-17 sprint
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-08-17 sprint to 2022-08-31 sprint
Updated by Peter Amstutz about 2 years ago
- Target version changed from 2022-08-31 sprint to 2022-09-14 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-09-14 sprint to 2022-09-28 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-09-28 sprint to 2022-10-12 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-10-12 sprint to 2022-10-26 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-10-26 sprint to 2022-11-09 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-11-09 sprint to 2022-11-23 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-11-23 sprint to 2022-12-21 Sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2022-12-21 Sprint to 2023-01-18 sprint
Updated by Peter Amstutz almost 2 years ago
- Target version changed from 2023-01-18 sprint to 2022-12-07 Sprint
Updated by Tom Clegg over 1 year ago
- Target version changed from 2022-12-07 Sprint to 2022-12-21 Sprint
Updated by Peter Amstutz over 1 year ago
- Target version changed from 2022-12-21 Sprint to 2023-01-18 sprint
Updated by Tom Clegg over 1 year ago
- Status changed from In Progress to Resolved