Comment 1 Peter Åstrand 2004-11-08 14:03:12 CET

Investigate. 

Comment 2 Peter Åstrand 2010-06-09 09:39:05 CEST

I think the easiest way to do this is to extend allowed_shadowers so that it supports group names using the "+" syntax, just like explicit_agentselection does. 

Comment 3 Peter Åstrand 2010-06-09 09:48:12 CEST

Created attachment 365 [details]
Script that sets allowed_shadowers from a group

Comment 4 Peter Åstrand 2012-11-19 11:21:41 CET

*** Bug 98 has been marked as a duplicate of this bug. ***

Comment 5 Peter Åstrand 2012-11-19 11:24:21 CET

This bug description is somewhat vague. The example from Les means both extending the configuration so that users in certain groups are allowed to shadowing, but also restrict shadowing which users can be shadowed. Extending allowed_shadowers with a group syntax (using "+") solves the former problem but not the latter: Members of those groups will still be able to shadow *anyone*.

Comment 6 Peter Åstrand 2012-11-19 11:39:10 CET

My suggestion is that this bug is solved by dropping allowed_shadowers altogether, and instead use "sudo": Thus, if user Alice is allowed to execute /usr/bin/thinlinc-login as user Bob, then Alice should be allowed to shadow Bob. There are several advantages of this approach:

* sudo already has a very extensible configuration file, using Extended Backus-Naur Form (EBNF). 


* In many cases, sysadmins have already configured sudoers properly. In principle, if Alice can execute thinlinc-login as Bob, she can create a TL session as Bob anyway (with some clever hacking). 


* Our code in VSM will be small; we will just need to execute sudo to check if Alice is allowed to shadow Bob. This can be done with either:

$ sudo -l -u Bob /usr/bin/thinlinc-login 
[sudo] password for Alice: 
/usr/bin/thinlinc-login

This just checks permissions. Or, we can actually execute it:

$ sudo -u Bob /usr/bin/thinlinc-login 
THINLINC-LOGIN: HELLO 4.0.0
THINLINC-LOGIN: CONNECTED MASTER

The above 2 commands requires the password, it seems. Listing all allowed commands with "sudo -l" does not, don't know why. VSM do have the password available, though, so we should be able to feed it to sudo, and we already have code for this. 


* In addition to extending the configuration to handle group shadowers as well as a fine grained control over who to shadow, the configuration allows for setting permissions based on other factors such as which machine you running on.

Comment 7 Peter Åstrand 2012-11-19 11:49:31 CET

(In reply to comment #6)

> The above 2 commands requires the password, it seems. Listing all allowed
> commands with "sudo -l" does not, don't know why. 

This turned out to be wrong, I was fooled by existing time stamp. The correct test command should be:

$ sudo -lAk -u Bob /usr/bin/thinlinc-login

Then, we set SUDO_ASKPASS to a helper program.

Comment 8 Peter Åstrand 2012-11-20 09:39:04 CET

Created attachment 459 [details]
Sudo implementation

It turns out that since vsmserver runs as root, dealing with passwords are not necessary. This allows for a very small and neat implementation. 

$ LANG=C svn diff | diffstat
 modules/thinlinc/vsm/vsmcommon.py |   30 +++++++++++++++++++++++-------
 vsmserver.hconf                   |    4 ----
 2 files changed, 23 insertions(+), 11 deletions(-)

Comment 9 Peter Åstrand 2012-11-20 09:58:55 CET

(In reply to comment #8)
> Created an attachment (id=459) [details]
> Sudo implementation

Some configuration examples. First, note that you can define an alias:

Cmnd_Alias TLSHADOW = /usr/bin/thinlinc-login

Then, a few examples:

* Les original request:
[/vsmserver/allowed_shadowers] 
all = root 
students = teachers admin 
teachers = headmaster

=>

root	    ALL=(ALL) 	    ALL  # This is sudo default, can also be limited to thinlinc-login
%teachers   ALL=(%students)  TLSHADOW
%admin      ALL=(%students)  TLSHADOW
%headmaster ALL=(%teachers)  TLSHADOW


* Replacing the previous "allowed_shadowers", ie users able to shadow anyone:

superuser   ALL=(ALL)        TLSHADOW


Of course there are also many possibilities with limiting shadowing to certain machines, netgroups, SELinux roles etc. Also, there's a /etc/sudoers.d/ which we could use for example if we want to create a web frontend.

Comment 10 Pierre Ossman 2016-12-15 10:48:25 CET

We'll start with the simple approach of just mapping users and groups and hopefully that should cover most use cases.

E.g. this config:

[/vsmserver/allowed_shadowers] 
@ALL = root 
+students = +teachers admin 
+teachers = headmaster 

This would mean that any user in the group "teachers" (or the user "admin") can shadow any user in the group "students".

Comment 13 Samuel Mannehed 2018-06-04 21:06:48 CEST

Another idea is to allow configuration such that anyone could shadow anyone with a "*" or to implement wildcard matching.

Comment 15 Samuel Mannehed 2018-06-18 09:35:45 CEST

(In reply to comment #14)
> Hello Samuel, does this issue fixed already? Or any source? Thanks

No, it's not fixed.