Project

General

Profile

Actions

Bug #19057

open

[controller] should not allow adding the same user+login to a VM more than one time

Added by Ward Vandewege 7 months ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Story points:
-

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


Subtasks 1 (1 open0 closed)

Task #19811: ReviewNewBrett Smith

Actions

Related issues

Related to Arvados Workbench 2 - Bug #19049: VM admin interface rough edgesResolvedStephen Smith05/13/2022

Actions
Related to Arvados - Story #18693: Deduplicate permission linksNewTom Clegg

Actions
Actions #1

Updated by Ward Vandewege 7 months ago

  • Related to Bug #19049: VM admin interface rough edges added
Actions #2

Updated by Ward Vandewege 7 months ago

  • Description updated (diff)
Actions #4

Updated by Tom Clegg 7 months 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.

Actions #5

Updated by Peter Amstutz 7 months ago

  • Target version changed from 2022-05-11 sprint to 2022-05-25 sprint
Actions #6

Updated by Ward Vandewege 7 months ago

  • Related to Story #18693: Deduplicate permission links added
Actions #7

Updated by Ward Vandewege 7 months 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.

Actions #8

Updated by Tom Clegg 7 months 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.

Actions #9

Updated by Peter Amstutz 7 months ago

  • Target version changed from 2022-05-25 sprint to 2022-06-08 sprint
Actions #10

Updated by Peter Amstutz 6 months ago

  • Target version changed from 2022-06-08 sprint to 2022-06-22 Sprint
Actions #11

Updated by Peter Amstutz 6 months ago

  • Target version changed from 2022-06-22 Sprint to 2022-07-06
Actions #12

Updated by Peter Amstutz 5 months ago

  • Target version changed from 2022-07-06 to 2022-07-20
Actions #13

Updated by Tom Clegg 5 months 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
Actions #14

Updated by Peter Amstutz 5 months ago

  • Target version changed from 2022-07-20 to 2022-08-03 Sprint
Actions #15

Updated by Peter Amstutz 4 months ago

  • Target version changed from 2022-08-03 Sprint to 2022-08-17 sprint
Actions #16

Updated by Peter Amstutz 4 months ago

  • Target version changed from 2022-08-17 sprint to 2022-08-31 sprint
Actions #17

Updated by Peter Amstutz 4 months ago

  • Target version changed from 2022-08-31 sprint to 2022-09-14 sprint
Actions #18

Updated by Peter Amstutz 3 months ago

  • Target version changed from 2022-09-14 sprint to 2022-09-28 sprint
Actions #19

Updated by Peter Amstutz 2 months ago

  • Target version changed from 2022-09-28 sprint to 2022-10-12 sprint
Actions #20

Updated by Peter Amstutz about 2 months ago

  • Target version changed from 2022-10-12 sprint to 2022-10-26 sprint
Actions #21

Updated by Peter Amstutz about 2 months ago

  • Target version changed from 2022-10-26 sprint to 2022-11-09 sprint
Actions #22

Updated by Peter Amstutz about 1 month ago

  • Target version changed from 2022-11-09 sprint to 2022-11-23 sprint
Actions #23

Updated by Peter Amstutz 17 days ago

  • Target version changed from 2022-11-23 sprint to 2022-12-21 Sprint
Actions #24

Updated by Peter Amstutz 4 days ago

  • Target version changed from 2022-12-21 Sprint to 2023-01-18 sprint
Actions #25

Updated by Peter Amstutz 3 days ago

  • Target version changed from 2023-01-18 sprint to 2022-12-07 Sprint
Actions #26

Updated by Peter Amstutz 3 days ago

  • Assigned To set to Tom Clegg
Actions

Also available in: Atom PDF