Bug 7254 - Administrator is forced to manage shadowers individually in configuration
Summary: Administrator is forced to manage shadowers individually in configuration
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VSM Server (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.10.0
Assignee: Henrik Andersson
URL:
Keywords: ossman_tester, relnotes
Depends on:
Blocks:
 
Reported: 2018-09-24 09:37 CEST by Henrik Andersson
Modified: 2018-10-04 12:55 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* Change should be backward compatible with old configuration * Documentation should describe how to enable a group of users for shadowing * Release note should be written * Administrator should be able to specify group in /shadowing/allowed_shadower to enable a group of shadowers


Attachments

Description Henrik Andersson cendio 2018-09-24 09:37:53 CEST
Managing shadowers with allowed_shadower can be an hassle due to the fact that users are specified individually. A possible solution would be to add support for adding a shadower group which would make managing of shadowers way simpler by eg. Administator is not required to edit configuration and restart vsmserver service each time a new shadower should be added.
Comment 3 Pierre Ossman cendio 2018-09-25 10:01:11 CEST
Unfortunately gr_mem isn't reliable and fails to deliver the group members in two cases:

 * When a user has the group as its default group

 * Some NSS backends refuse to enumerate members for performance reasons

The safe way is to use initgroups(). We have existing code for this for the sub-cluster check, and allowed_groups. Should be able to use that.
Comment 10 Henrik Andersson cendio 2018-09-28 15:35:30 CEST
Tester should verify that following functions works as expected:

 - root should be able to terminate a user session (tlwebadm)

 - Shadower by uid or user should be able to terminate a user session

 - Shadower by uid or user group should be able to retrieve sessions
   list for any user

 - Shadower by uid of user group should be able to shadow any user session
Comment 11 Henrik Andersson cendio 2018-10-01 14:44:55 CEST
(In reply to comment #10)
> Tester should verify that following functions works as expected:
> 
>  - root should be able to terminate a user session (tlwebadm)
> 

Works as expected

>  - Shadower by uid or user should be able to terminate a user session
>

There is no way through the client to kill a user session. This means
that we have an ACL implementation in handler which is never used.
We should remove the rights for shadower to terminate a session for
clarity.

>  - Shadower by uid or user group should be able to retrieve sessions
>    list for any user
> 

Works as expected

>  - Shadower by uid of user group should be able to shadow any user session
>

Works as expected, and if not memeber of group nor specified by name access is denied as expected.
Comment 13 Henrik Andersson cendio 2018-10-01 14:51:35 CEST
(In reply to comment #11)
> (In reply to comment #10)
> 
> >  - Shadower by uid or user should be able to terminate a user session
> >
> 
> There is no way through the client to kill a user session. This means
> that we have an ACL implementation in handler which is never used.
> We should remove the rights for shadower to terminate a session for
> clarity.
> 

Commit r33759 remove the access for shadower to kill a session.
Comment 17 Pierre Ossman cendio 2018-10-04 12:55:16 CEST
Works well. Tested on Ubuntu 18.04

> * Change should be backward compatible with old 
>   configuration

Could not come up with any configuration that would be valid in the old version and not work in the new version (except a username that starts with "+", but that's an acceptable loss).

> * Documentation should describe how to enable a group
>   of users for shadowing

Looks good.

> * Release note should be written

Looks good.

> * Administrator should be able to specify group in
>   /shadowing/allowed_shadower to enable a group of
>   shadowers

Works. Tried with both a user's default group as well as an additional group.

Note You need to log in before you can comment on or make changes to this bug.