[X2go-dev] Use case for an x2go user-group

[John A. Sullivan III]

On Fri, 2011-02-18 at 20:14 +0100, Alexander Wuerstlein wrote:
> <snip>> 
> > Are you implying that every user on any x2go server would be able to
> > launch a remote x2go desktop by default?
> 
> Yes.
> 
> > We don't have any problems with the current mechanism of 'x2gousers'
> > providing the control.
> > 
> > And in fact in most OS you see 'groups' are specifically there for the
> > express purpose of controlling access to functionality.
> 
> Yes, but in large setups, groups become very hard to manage. Large
> groups with thousands of users tend to be an administration burden, also
> a large number of additional groups for each user tends to be
> problematic with many operating systems or setups (NIS, SQL, older
> unices, etc).
Hmm . . . I can see that backfiring in our scenario.  Of course, our
scenario shouldn't drive the overall development but I'll share my
concerns in case others have them, too.

Because we envision a very large environment, we are an LDAP shop
(CentOS Directory Server).  There are very, very few local accounts.  We
are not using N-to-1 X2GoServer but rather 1-to-1 - each X2Go user has
their own VM.  We use a local x2gousers group on the VM.  We create it
and add the user to it (in fact, the VM hostname is the same as the
globally unique user uid) as part of the VM creation.  This locks each
user to a VM which is handy for both billing and non-repudiation.
Because we fix each IP, all activity is known to come from that user and
only that user (handy for schools or any other organization sensitive to
IT abuse).  In the proposed scenario, any valid LDAP user from any
client in our multi-tenant environment could conceivably start an X2Go
session on any VM thus destroying the control and accountability we
implemented exactly because we anticipate a large environment.

However, we do appreciate that you have given us options which I'll
address below.
> 
> > In many companies only certain employees such as field personnel or
> > sales are permitted remote desktop access.  And the 'x2gousers' group
> > suits this purpose well.
> 
> Yes, it does on small scales. And our approach wouldn't make the
> 'x2gousers' group go away if you still want to use it: You can simply
> make the x2gowrapper executable only for that group and not for others.
> Then you have exactly the same functionality as with 'sudo', but without
> the hassle of setting up the sudo configuration (wich does never seem to
> work automatically on installation). That would also be the suggested
> migration path i guess. Additionally you can of course use database
> black/whitelists, or you can set x2gowrapper o+rx and only use database
> black/whitelists. In that sense our approach would also be far more
> flexible than the current sudo approach.
<snip>

I suppose this is true and appreciate the flexibility.  Just as we
automate the creation of the group, we could simply change the group
ownership of x2gowrapper to the user's personal group and remove world
access.  Is that a correct understanding of how we could use what you
are proposing? I do hope those ownership and permissions changes wold be
preserved across an update.  Otherwise, I could see a security
nightmare.

Again, our use shouldn't drive this decision but I wonder how many
others have variations on our theme for issues like billing, security,
and non-repudiation.  Thanks again for opening the discussion; I hope it
is proving helpful rather than burdensome! - John