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