Project

General

Profile

Actions

Bug #19057

closed

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

Added by Ward Vandewege almost 2 years ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
-
Target version:
Start date:
01/18/2023
Due date:
% Done:

100%

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

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 (0 open1 closed)

Task #19811: ReviewClosedBrett Smith01/18/2023

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 linksResolvedTom Clegg01/03/2023

Actions
Actions #1

Updated by Ward Vandewege almost 2 years ago

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

Updated by Ward Vandewege almost 2 years ago

  • Description updated (diff)
Actions #4

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

Actions #5

Updated by Peter Amstutz almost 2 years ago

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

Updated by Ward Vandewege almost 2 years ago

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

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

Actions #8

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

Actions #9

Updated by Peter Amstutz almost 2 years ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Tom Clegg over 1 year 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 over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz over 1 year ago

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

Updated by Peter Amstutz about 1 year ago

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

Updated by Peter Amstutz about 1 year ago

  • Assigned To set to Tom Clegg
Actions #27

Updated by Tom Clegg about 1 year ago

  • Story points set to 1.0
Actions #28

Updated by Tom Clegg about 1 year ago

  • Target version changed from 2022-12-07 Sprint to 2022-12-21 Sprint
Actions #29

Updated by Peter Amstutz about 1 year ago

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

Updated by Tom Clegg about 1 year ago

  • Status changed from New to In Progress

see #18693

Actions #31

Updated by Tom Clegg about 1 year ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF