Subject: Re: [X2Go-Dev] Bug#372: Bug#372: x2goadmin writes to users homes

From: Reinhard Tartler <[email-masked]>
Date: Mon, 16 Dec 2013 09:46:36 -0500

On Dec 16, 2013 9:40 AM, "Alexander Wuerstlein" <[email-masked]> wrote:
>
> On 13-12-16 15:33, Reinhard Tartler <[email-masked]> wrote:
> > On Dec 16, 2013 8:59 AM, "Alexander Wuerstlein" <
> > [email-masked]> wrote:
> > >
> > > On 13-12-16 08:49, Mike Gabriel <[email-masked]>
wrote:
> > > > Hi Reinhard,
> > > >
> > > > On  So 15 Dez 2013 01:13:35 CET, Reinhard Tartler wrote:
> > > >
> > > > >Package: x2goserver
> > > > >Severity: serious
> > > > >
> > > > >Hi,
> > > > >
> > > > >my understanding of the x2goadmin code [code], end of sub
add_user, is
> > > > >that the code tries to write the sql password in users homes. This
> > > > >will fail for installations that have the user homes on NFS with
the
> > > > >option "rootsquash" mounted.
> > > > >
> > > > >I set the severity to "serious" because I imagine that this is a
> > > > >rather common scenario.
> > > > >
> > > > >Also, this approach has another problem: Imagine you want to give
> > > > >access to the unix group "staff"? According to the documentation,
you
> > > > >can use the options "--addgroup" and "--rmgroup" for this. What if
a
> > > > >new employee joins the company later and wants to use x2go? In this
> > > > >case you need to call x2godbadmin for this new user again, which is
> > > > >suboptimal.
> > > > >
> > > > >Is there really no way to get around generated user passwords?
> > >
> > > There is a way that could work: If configured correctly, postgresql
can
> > > use GSSAPI (Kerberos) Authentication. That way, the user is
> > > authenticated using his login ticket cache which is created anyways.
> > > If necessary, one could also provide a keyfile for the cleanup-cronjob
> > > so that it can at least access the database with sufficient
permissions.
> >
> > That would be an option if you are OK to break passwordless ssh key
> > authentication logins.
> >
> > If you really wanted to go the kerberos route, you would have to create
> > special db principals that can only access the db, and stash a
passwordless
> > keyfile in the users home.
>
> Yes, that is correct. One more thing that could also work, but is ugly,
> would be 'ident' authentication in postgresql. But that would of course
> mean that one needs a sufficiently trustable identd on all machines.

Only on the x2go server, not the machine the user is connecting from.

For me, this seems perfectly appropriate in this case.

Reinhard