From siretart@gmail.com Mon Dec 16 15:46:37 2013 Received: (at 372) by bugs.x2go.org; 16 Dec 2013 14:46:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_LOW,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ymir (Postfix) with ESMTPS id 728E45DB16 for <372@bugs.x2go.org>; Mon, 16 Dec 2013 15:46:37 +0100 (CET) Received: by mail-qe0-f53.google.com with SMTP id nc12so3922524qeb.12 for <372@bugs.x2go.org>; Mon, 16 Dec 2013 06:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TaK4h7jbhFGzNNbtAj0239+DZpy+g1ayKBl6SMtBJz4=; b=XMr91eKuv8lhN/Z/GRNfr1Csx8yqwh9IsY3yXplkLzAXk2zJS7mmM8mo74+xuSdkZ+ C0CSuPNz/VuytoII4VMXjlhucP0TRgUWod3uJNxRxYGdOJ2FqPl5In/+6DIikGXpXTBH XT6kNCWEBEOcdSQADLFSxZAnFNEoSB4zP5+zS2DCQhCGkxOSEjUNk2L6hdDJMTSSSdp2 rjbMpKETUac3OEQ1Sb6b7XWv308f1pz+5ECv90eM8RIPhkJ5iE/C++p2Ar7n6aJIhUpa pP71lFBuPVznY+RU5riu6RE+Rsgrxs6fAuUdjW2jmuhWpYvGI6QSwA9CUEcF/141ZFrk QKuA== MIME-Version: 1.0 X-Received: by 10.224.47.73 with SMTP id m9mr32458954qaf.23.1387205196459; Mon, 16 Dec 2013 06:46:36 -0800 (PST) Received: by 10.96.78.227 with HTTP; Mon, 16 Dec 2013 06:46:36 -0800 (PST) Received: by 10.96.78.227 with HTTP; Mon, 16 Dec 2013 06:46:36 -0800 (PST) In-Reply-To: <20131216144026.GG24005@cip.informatik.uni-erlangen.de> References: <20131216073434.Horde.PERNE-ga0mmuL2Mohe-6VA2@mail.das-netzwerkteam.de> <20131216135940.GF24005@cip.informatik.uni-erlangen.de> <20131216144026.GG24005@cip.informatik.uni-erlangen.de> Date: Mon, 16 Dec 2013 09:46:36 -0500 Message-ID: Subject: Re: [X2Go-Dev] Bug#372: Bug#372: x2goadmin writes to users homes From: Reinhard Tartler To: Alexander Wuerstlein Cc: 372@bugs.x2go.org, Mike Gabriel , o.schneyder@phoca-gmbh.de, x2go-dev@lists.berlios.de Content-Type: multipart/alternative; boundary=001a1134a7faf74fd704eda7e0e8 --001a1134a7faf74fd704eda7e0e8 Content-Type: text/plain; charset=ISO-8859-1 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 --001a1134a7faf74fd704eda7e0e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Dec 16, 2013 9:40 AM, "Alexander Wuerstlein" <arw@cs.fau.de> wrote:
>
> On 13-12-16 15:33, Reinhard Tartler <siretart@gmail.com> wrote:
> > On Dec 16, 2013 8:59 AM, "Alexander Wuerstlein" < > > snalwu= er@cip.informatik.uni-erlangen.de> wrote:
> > >
> > > On 13-12-16 08:49, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote:=
> > > > Hi Reinhard,
> > > >
> > > > On =A0So 15 Dez 2013 01:13:35 CET, Reinhard Tartler wro= te:
> > > >
> > > > >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 us= ers homes. This
> > > > >will fail for installations that have the user home= s 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 yo= u want to give
> > > > >access to the unix group "staff"? Accordi= ng to the documentation, you
> > > > >can use the options "--addgroup" and &quo= t;--rmgroup" for this. What if a
> > > > >new employee joins the company later and wants to u= se 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, pos= tgresql can
> > > use GSSAPI (Kerberos) Authentication. That way, the user is<= br> > > > authenticated using his login ticket cache which is created = anyways.
> > > If necessary, one could also provide a keyfile for the clean= up-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 k= ey
> > 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 pa= sswordless
> > 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 connect= ing from.

For me, this seems perfectly appropriate in this case.

Reinhard

--001a1134a7faf74fd704eda7e0e8--