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.
Created attachment 365 [details]
Script that sets allowed_shadowers from a group
*** Bug 98 has been marked as a duplicate of this bug. ***
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*.
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:
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.
(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.
Created attachment 459 [details]
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(-)
(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:
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.
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:
@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".
Another idea is to allow configuration such that anyone could shadow anyone with a "*" or to implement wildcard matching.
(In reply to comment #14)
> Hello Samuel, does this issue fixed already? Or any source? Thanks
No, it's not fixed.