From unknown Fri Mar 29 03:27:44 2024 X-Loop: owner@bugs.x2go.org Subject: Bug#372: [X2Go-Dev] Bug#372: Bug#372: x2goadmin writes to users homes Reply-To: Reinhard Tartler , 372@bugs.x2go.org Resent-From: Reinhard Tartler Resent-To: x2go-dev@lists.berlios.de Resent-CC: X2Go Developers X-Loop: owner@bugs.x2go.org Resent-Date: Mon, 16 Dec 2013 14:33:02 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.x2go.org X-X2Go-PR-Message: followup 372 X-X2Go-PR-Package: x2goserver X-X2Go-PR-Keywords: Received: via spool by 372-submit@bugs.x2go.org id=B372.138720431031361 (code B ref 372); Mon, 16 Dec 2013 14:33:02 +0000 Received: (at 372) by bugs.x2go.org; 16 Dec 2013 14:31:50 +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-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ymir (Postfix) with ESMTPS id B7FF85DB16 for <372@bugs.x2go.org>; Mon, 16 Dec 2013 15:31:49 +0100 (CET) Received: by mail-qa0-f46.google.com with SMTP id f11so1564074qae.12 for <372@bugs.x2go.org>; Mon, 16 Dec 2013 06:31:48 -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=79zbFEr13g+A8tDAF9uYzV/fmYhjxGC86Te6xe91a5g=; b=PEPp8bzxfBLqO3oadnAck8fwiV4QR4OCVuaQ00frT/qABFvwdq/7ouHgx9qLfN8/ut f3YfOkVgrzFlLViiQE4FrEYvOH6H8xm7NFafYHT66pYTNHFWmTxxQRHMffD7zUkwoBK2 ASDzt8nzXHp7GhmIjArEIVQC+Okubs0hnrxdcdF7nl9/ccPrYWdGTzwHyBoZxVucBPjN cfUQoVJhDlyrnkpAc6UqdJmLwUW6Z1q2WkvHxPc/+0N9tSmV/d71iTytSQyXOcZpEcJ4 +uYmTfE8Go5FDqsgq95rLQ7i36s8YA4VjYk8oS70Ese3Q8PnSDBU6J+CmeV6PrNLOr1v 7MiA== MIME-Version: 1.0 X-Received: by 10.224.37.1 with SMTP id v1mr32729366qad.29.1387204308479; Mon, 16 Dec 2013 06:31:48 -0800 (PST) Received: by 10.96.78.227 with HTTP; Mon, 16 Dec 2013 06:31:48 -0800 (PST) Received: by 10.96.78.227 with HTTP; Mon, 16 Dec 2013 06:31:48 -0800 (PST) In-Reply-To: <20131216135940.GF24005@cip.informatik.uni-erlangen.de> References: <20131216073434.Horde.PERNE-ga0mmuL2Mohe-6VA2@mail.das-netzwerkteam.de> <20131216135940.GF24005@cip.informatik.uni-erlangen.de> Date: Mon, 16 Dec 2013 09:31:48 -0500 Message-ID: From: Reinhard Tartler To: Alexander Wuerstlein Cc: 372@bugs.x2go.org, o.schneyder@phoca-gmbh.de, Mike Gabriel , x2go-dev@lists.berlios.de Content-Type: multipart/alternative; boundary=001a11c2b25609b5a804eda7acef --001a11c2b25609b5a804eda7acef Content-Type: text/plain; charset=ISO-8859-1 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. > > But I have never tried this with x2go and don't know if it would work. > > > > Ciao, > > Alexander Wuerstlein. --001a11c2b25609b5a804eda7acef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Dec 16, 2013 8:59 AM, "Alexander Wuerstlein" <snalwuer@cip.informatik.uni-e= rlangen.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 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 w= ith the
> > >option "rootsquash" mounted.
> > >
> > >I set the severity to "serious" because I imagine t= hat 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 "--rmgrou= p" for this. What if a
> > >new employee joins the company later and wants to use x2go? I= n this
> > >case you need to call x2godbadmin for this new user again, wh= ich is
> > >suboptimal.
> > >
> > >Is there really no way to get around generated user passwords= ?
>
> There is a way that could work: If configured correctly, postgresql ca= n
> 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 permission= s.

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 hav= e to create special db principals that can only access the db, and stash a = passwordless keyfile in the users home.

>
> But I have never tried this with x2go and don't know if it would w= ork.
>
>
>
> Ciao,
>
> Alexander Wuerstlein.

--001a11c2b25609b5a804eda7acef--