X2Go Bug report logs - #354
Make x2goagent listening to TCP connections configurable in x2goserver.conf

Full log

Message #91 received at 354@bugs.x2go.org (full text, mbox, reply):

Received: (at 354) by bugs.x2go.org; 9 Dec 2013 08:08:32 +0000
From mike.gabriel@das-netzwerkteam.de  Mon Dec  9 09:08:32 2013
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,
	RCVD_IN_DNSWL_BLOCKED,URIBL_BLOCKED autolearn=ham version=3.3.2
Received: from freya.das-netzwerkteam.de (freya.das-netzwerkteam.de [88.198.48.199])
	by ymir (Postfix) with ESMTPS id 27F975DA7B
	for <354@bugs.x2go.org>; Mon,  9 Dec 2013 09:08:32 +0100 (CET)
Received: from grimnir.das-netzwerkteam.de (grimnir.das-netzwerkteam.de [78.46.204.98])
	by freya.das-netzwerkteam.de (Postfix) with ESMTPS id C3B0AA37;
	Mon,  9 Dec 2013 09:08:30 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id B10143C058;
	Mon,  9 Dec 2013 09:08:30 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at grimnir.das-netzwerkteam.de
Received: from grimnir.das-netzwerkteam.de ([127.0.0.1])
	by localhost (grimnir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id J81cf3mhcLgc; Mon,  9 Dec 2013 09:08:30 +0100 (CET)
Received: from grimnir.das-netzwerkteam.de (localhost [127.0.0.1])
	by grimnir.das-netzwerkteam.de (Postfix) with ESMTPSA id 55E0A3C015;
	Mon,  9 Dec 2013 09:08:29 +0100 (CET)
Received: from nocatv2.tng.de (nocatv2.tng.de [213.178.75.58]) by
 mail.das-netzwerkteam.de (Horde Framework) with HTTP; Mon, 09 Dec 2013
 08:08:29 +0000
Date: Mon, 09 Dec 2013 08:08:29 +0000
Message-ID: <20131209080829.Horde.Lo0aSm7GN8VVLm26eoL6wA1@mail.das-netzwerkteam.de>
From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
To: Nick Ingegneri <n_ingegneri@yahoo.com>, Stefan Baur
 <newsgroups.mail2@stefanbaur.de>
Cc: Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de>,
 "354@bugs.x2go.org" <354@bugs.x2go.org>
Subject: Re: [X2Go-Dev] Bug#354: Bug#354: Make x2goagent listening to TCP
 connections configurable in x2goserver.conf
References: <20131206112155.Horde.SbfwdHK-kyPj8MElQt3mrQ1@mail.das-netzwerkteam.de>
 <52A1BBAE.90909@stefanbaur.de>
 <20131206120625.Horde.SkFUuwsrCrkJ3OMw64wKaA1@mail.das-netzwerkteam.de>
 <52A1C089.3090709@stefanbaur.de>
 <1386351855.74486.YahooMailNeo@web122101.mail.ne1.yahoo.com>
 <52A21285.7090407@stefanbaur.de>
 <20131206195600.GA26961@cip.informatik.uni-erlangen.de>
 <20131207204759.Horde.ykUqekidzsjvppwa3ypAiQ7@mail.das-netzwerkteam.de>
 <52A39369.8050408@stefanbaur.de>
 <20131207215054.Horde.bR0h7aVrFSgs8VMWz2Sp2g2@mail.das-netzwerkteam.de>
 <1386515582.31556.YahooMailNeo@web122106.mail.ne1.yahoo.com>
In-Reply-To: <1386515582.31556.YahooMailNeo@web122106.mail.ne1.yahoo.com>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4)
Accept-Language: en,de
Organization: DAS-NETZWERKTEAM
X-Originating-IP: 213.178.75.58
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101
 Firefox/23.0 Iceweasel/23.0
Content-Type: multipart/signed; boundary="=_IYbgqfo1V7bk8hZ1RGA3xA4";
 protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0

[Message part 1 (text/plain, inline)]

Hi Nick,

On  So 08 Dez 2013 16:13:02 CET, Nick Ingegneri wrote:

>> On Saturday, December 7, 2013 2:51 PM, Mike Gabriel  
>> <mike.gabriel@das-netzwerkteam.de> wrote:
>>
>> Control: tag -1 wontfix
>> Control: close -1
>>
>> Hi Stefan,
>>
>> On  Sa 07 Dez 2013 22:30:17 CET, Stefan Baur wrote:
>>
>>> [...]
>>
>>> Man, where are my pills, I don't want to go into full Theo de  
>>> Raadt mode ...
>>
>> Okokokok... heard!
>>
>> @Nick: please place a copy of x2gostartagent into
>>  /usr/local/bin for a transition period and modify it to your  
>> needs. We won't reenable TCP listening in upstream X2Go. For long  
>> term usage of X2Go, adapt your workflows to a more secure model.
>>
>> Mike

> Mike, Stefan, Alexander, et al.,
>
> I was watching this conversation play out before replying.
>
> It isn't going to be fruitful to be pulled into a long discussion  
> about the specifics of our compute environment. There are many  
> assumptions being made in this discussion that aren't correct, and  
> saying "don't use TCP" without knowing these specifics is ignorant.  
> There are industry-standard commercial products that disabling TCP  
> breaks. Our IT department cannot decide to stop supporting TCP; it  
> is the users and our commercial suppliers who determine what IT has  
> to support.
>
> I think that because I used "xhost +" in my original debugging  
> example, the assumption was immediately made that "xhost +" was my  
> primary concern. My primary concern is that disabling TCP
>  breaks almost every possible use model except for one narrow case  
> (ssh). Among other things, it breaks the MIT-MAGIC-COOKIE-1  
> mechanism. While there are very valid concerns regarding use of TCP  
> on the internet, we have a different hierarchy of concerns regarding  
> what happens on our internal network.
>
> One incorrect assumption that is being made in this discussion is  
> that some action to initiate the display can take place on the  
> system the user is logged into, or that the user is even involved in  
> initiating the display.  Consider this use model:
>
> 1: User's display is system100:24
> 2: Automated processes, with no user involvement, launch a program  
> on a randomly chosen system (let's say it is system204).
> 3: The new program running on system204 now has to connect back to  
> the display on system100:24
>
> Personally, the problem is solved for us for at least the moment and  
> we can move forward with what we are trying to do. Having to
>  edit /usr/bin/x2gostartagent every time we install or upgrade the  
> package is inelegant and creates additional administrative overhead,  
> but it is manageable.
>
> This is your project, not mine, I merely came to the mailing list  
> with a problem looking for a solution. I can tell you that our use  
> model is extremely common in industry and that breaking it will  
> render X2Go unusable. Of the five alternatives we are looking at,  
> X2Go was the only one with TCP disabled. Most system administrators  
> trying to set up an evaluation of X2Go aren't typically going to dig  
> further than the documentation and config files in trying to fix  
> this problem. If you make fixing it so obscure that it escapes these  
> system administrators, then X2Go isn't going to get very far in  
> those evaluations.
>
> How accessible or obscure you make this setting is up to you as  
> developers, but saying to users "your use model is wrong" doesn't  
> show appreciation for the diversity of ways that X is used in  
> production.
>
> Cheers,
> Nick

Thanks again for this valuable feedback. I must say, I am a little  
undecided on this. I have been working at a university institute where  
X-servers with TCP disabled also simply would have blocked all  
established workflows.

I will discuss this issue personally with Alex (Oleksandr Shneyder)  
and the two of use will then decide how to procede here.

@Stefan: I completely get your concerns, but I also here quite a big  
deal of paranoia. I am not working on X2Go to protect X2Go users from  
themselves, I am working on X2Go to provide a flexible remote desktop  
solution.

light+love,
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

[Message part 2 (application/pgp-signature, inline)]

Send a report that this bug log contains spam.