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

[John A. Sullivan III]

On Fri, 2011-02-18 at 19:18 +0100, Reinhard Tartler wrote:
> On Fri, Feb 18, 2011 at 18:52:28 (CET), John A. Sullivan III wrote:
> 
> > On Fri, 2011-02-18 at 17:18 +0100, Reinhard Tartler wrote:
> >> <snip>The question is if there was a legitimate use-case for having users
> >> that can login via ssh, but are not in the x2gousers group, i.e., cannot
> >> login via x2go.
> > <snip>
> > It's a bit of a stretch but I could see it in hosted environments like
> > ours.  Although we do not do this specifically, let's say there is an
> > application server which is also hosting X2Go desktops.  The client may
> > have an external consultant/support person who should not have a
> > billable X2Go desktop but does need console access to support the
> > application via, say, a VPN connection.
> >
> > Come to think of it, I suppose that is not just a hosting issue.  A
> > company using X2Go may not want to give desktop access to consultants
> > who are supporting applications running on the same server.  That sounds
> > like poor practice but there may be some legitimate reason to do that
> > which we haven't considered.  Is that more in line with what you were
> > asking? Thanks - John
> 
> Indeed, that would.
> 
> AFAIUI, you also agree that this is a pretty obscure corner case that is
> not worth to have as default. Therefore, I suggest to drop the sudo
> stuff completely and install x2gowrapper as 'suid x2gouser' so that no
> additional configuration is necessary. With this change, the use-case
> above doesn't work anymore.
> 
> In order to restore that functionality, the database schema would need
> to be extended to implement a blacklist. And in fact, your explanation
> kindof confirms that a blacklist would be more suited than the current
> whitelist (i.e., the x2gousers group) approach.
> 
> 
> 
I'm ambivalent.  In the little development I've done, unless I'm
protecting my users from doing really, really dangerous things, I tend
to err on the side of not restricting them because of the countless ways
they can think of using my application that never occurred to me.  Of
course, we are not preventing them - just making it harder.  I am
somewhat ignorant of the motivation to make the change (I'm sure it is
valid) so I'm not in a position to weigh the advantages and
disadvantages.  I would be quite curious to see what others say and
really appreciate your asking before simply implementing it - John