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