On Dec 16, 2013 9:40 AM, "Alexander Wuerstlein" wrote: > > On 13-12-16 15:33, Reinhard Tartler wrote: > > On Dec 16, 2013 8:59 AM, "Alexander Wuerstlein" < > > snalwuer@cip.informatik.uni-erlangen.de> wrote: > > > > > > On 13-12-16 08:49, Mike Gabriel 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