From unknown Fri Mar 29 13:29:32 2024 X-Loop: owner@bugs.x2go.org Subject: Bug#354: [X2Go-Dev] Bug#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf Reply-To: Nick Ingegneri , 354@bugs.x2go.org Resent-From: Nick Ingegneri Resent-To: x2go-dev@lists.berlios.de Resent-CC: X2Go Developers X-Loop: owner@bugs.x2go.org Resent-Date: Fri, 06 Dec 2013 17:48:01 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.x2go.org X-X2Go-PR-Message: followup 354 X-X2Go-PR-Package: x2goserver X-X2Go-PR-Keywords: Received: via spool by 354-submit@bugs.x2go.org id=B354.138635185828372 (code B ref 354); Fri, 06 Dec 2013 17:48:01 +0000 Received: (at 354) by bugs.x2go.org; 6 Dec 2013 17:44:18 +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=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_BLOCKED,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from nm14-vm3.bullet.mail.ne1.yahoo.com (nm14-vm3.bullet.mail.ne1.yahoo.com [98.138.91.144]) by ymir (Postfix) with SMTP id 478955DB05 for <354@bugs.x2go.org>; Fri, 6 Dec 2013 18:44:17 +0100 (CET) Received: from [98.138.100.118] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 06 Dec 2013 17:44:16 -0000 Received: from [98.138.101.173] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 06 Dec 2013 17:44:16 -0000 Received: from [127.0.0.1] by omp1084.mail.ne1.yahoo.com with NNFMP; 06 Dec 2013 17:44:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 28980.33625.bm@omp1084.mail.ne1.yahoo.com Received: (qmail 74721 invoked by uid 60001); 6 Dec 2013 17:44:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1386351855; bh=HaGThh4jyZwSUAo75BDgjXaGidz5VM/53BsnYXO2AyY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Vn65PnLExZ/V0Cvm4jFty8jiyeJyhF7CjmcnoSdisHHhJihjlYAZhIgtM1s+MtDusbrEv+YfetUCxmOGbBMf0G5369yj79Plw90GMU8KiglzU2TQ9Xr6Pt5u8SMFzzALvTpuQSjCNL5GeB6WtckIT1qWsTGVfHbNWiKG9vOTSRo= DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zWYT1Y0tUUHsnHG2+zizcbR6ucVRumUcpOm5SwvXWajLgQigvYzggmR4NcKl+C/Dfi8ZqqkQAYrZFUmjygJoNgJ7XriOYZFh6cxQ2g1CbxyAJ7QBlHS55tCPmQ0OGD7HFw47Q5HxvGJNn98+9V9qRzV5daNpTqM9u86Uynoi+LI=; X-YMail-OSG: zteU.RIVM1l6fAyCvDAR6an7Ehp746Gw9IO0.22qw7lw0gr wL9PSxOTQO3XaUahKwlFf0XI.aJ1sDEEDLVpnY7TIKlYDX93hmEfhiqyHA1D beQePj4LIUMoHDyZfiVa6VqxhbObg0bSU5LhQCua3ltrkUqNTmAirRrYZUVF 02FIvQzUAME_mXsJ7UXDzr9lWxWMwFU51Y3ZDJS5TUHFZiCXsI6IBCHyZTC2 hre4xz.t.vMGx_fXd29WYwZSvZSDcqaLRB_XTOMSu7gfcTFcEHBYILQIQTGe iRukhk36yPrkhdmJW9dDmOUwHEIuKLy6_Pmuyw3a_FrHBktynffUzkVeI9d5 OxUD9pOKfc7CcB0wMB.gh.LkS_pcNyGV74ZnuxNL1QpPqDMLHDW.vqtt8_D5 QIIGcSMWIgNwCBIfC6MnXVQIggP45R.sM2EK4WMiB4xvcHM1CAcrHoZhoslL ovrggeFVT2Y4MNqgliM55A36O0i.wRSlUttPJ4aBv4PhyrviULsWwVlv_ZQp IKJAsmdrZ_FcapgXoJuFCgwk_X5TbGwqtFiEio089ZYrr2cWude0eb3djS9A hcAfA88LCPN6jJdehL5Y- Received: from [107.1.64.82] by web122101.mail.ne1.yahoo.com via HTTP; Fri, 06 Dec 2013 09:44:15 PST X-Rocket-MIMEInfo: 002.001,SGkgTWlrZSwgU3RlZmFuLAoKClNpbmNlIEknbSB0aGUgb25lIHdobyBicm91Z2h0IHRoaXMgdXAsIEknbGwgdHJ5IHRvIGJlIGFuIGFkdm9jYXRlIGZvciB3aHkgdGhpcyBjaGFuZ2UgaXMgYSBnb29kIHRoaW5nIGZvciBjZXJ0YWluIHVzZXJzLgoKCldlIGFyZSBldmFsdWF0aW5nIFgyR28gZm9yIHVzZSBpbiBhbiBleGlzdGluZyBjb3Jwb3JhdGUgdGVjaG5pY2FsIGNvbXB1dGUgZW52aXJvbm1lbnQuIFRoZXJlIGlzIGEgc2hvcnRjb21pbmcgaW4gb3VyIGN1cnJlbnQgdGhpbiBjbGllbnQgc29sdXRpb24gKG4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <20131206112155.Horde.SbfwdHK-kyPj8MElQt3mrQ1@mail.das-netzwerkteam.de> <52A1BBAE.90909@stefanbaur.de> <20131206120625.Horde.SkFUuwsrCrkJ3OMw64wKaA1@mail.das-netzwerkteam.de> <52A1C089.3090709@stefanbaur.de> Message-ID: <1386351855.74486.YahooMailNeo@web122101.mail.ne1.yahoo.com> Date: Fri, 6 Dec 2013 09:44:15 -0800 (PST) From: Nick Ingegneri To: Stefan Baur , Mike Gabriel Cc: "354@bugs.x2go.org" <354@bugs.x2go.org>, "x2go-dev@lists.berlios.de" In-Reply-To: <52A1C089.3090709@stefanbaur.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1593584224-1574623545-1386351855=:74486" ---1593584224-1574623545-1386351855=:74486 Content-Type: text/plain; charset=us-ascii Hi Mike, Stefan, Since I'm the one who brought this up, I'll try to be an advocate for why this change is a good thing for certain users. We are evaluating X2Go for use in an existing corporate technical compute environment. There is a shortcoming in our current thin client solution (not NX) and we need to identify a replacement. This environment contains hundreds of users, hundreds of systems, dozens of applications, and an uncountable number of scripts. X2Go is being considered against several alternatives. Whatever solution we choose has to work within the existing environment and support the existing workflow. Our current workflow uses a mixture of xhost and xauth to allow xclients to connect to xservers. While "ssh -Y" may technically be an elegant solution, requiring it would break our existing tools, processes, and scripts. Simply put, any thin client solution we deploy has to support TCP connections if it is to meet our requirement of not disrupting how work is currently done. I acknowledge that there is a security issue with TCP connections in X11, but that is an architectural issue with X11 itself and not with X2Go per se. If the developers of X2Go were to make TCP connections impossible then effectively the defined security model of X11 (as documented in places like the XSecurity and Xauth man pages) would be broken. TCP is part of how X11 works. Once it became apparent in our testing that exporting displays didn't work as expected, the system administrator who installed it went through the configuration files and documentation looking for a solution. He couldn't find one, so he escalated it to me to look into. If we hadn't been able to find a fix it would have ruled out X2Go from further consideration, which would have been unfortunate as it is currently our leading choice for this particular need. Hopefully the above helps persuade you that there is a need for some users to be able to continue to support the existing X11 security model (including TCP). If you accept that point, then it seems there should be a more elegant way of enabling TCP than editing the x2gostartagent file. As someone brand new to looking at the project, files like x2goagent.options or x2goserver.conf are the obvious places I would expect to find an option to make this change. Thanks, Nick On Friday, December 6, 2013 5:16 AM, Stefan Baur wrote: Am 06.12.2013 13:06, schrieb Mike Gabriel: > The default should be ,,disabled'', of course. However, I think that we > should support people that want to use X2Go in their setup as a > replacement for *NX*. Making something configurable and putting a big > red warning sign above the configuration should be ok IMHO. > Feedback? Is there no way of assisting this user in migrating away from NX, other than raping our codebase like that? What's wrong with using ssh -X / ssh -Y, which was previously suggested to the user? Maybe some more information on what the user is trying to accomplish would help us come up with a better solution. -Stefan ---1593584224-1574623545-1386351855=:74486 Content-Type: text/html; charset=us-ascii
Hi Mike, Stefan,

Since I'm the one who brought this up, I'll try to be an advocate for why this change is a good thing for certain users.

We are evaluating X2Go for use in an existing corporate technical compute environment. There is a shortcoming in our current thin client solution (not NX) and we need to identify a replacement. This environment contains hundreds of users, hundreds of systems, dozens of applications, and an uncountable number of scripts. X2Go is being considered against several alternatives.

Whatever solution we choose has to work within the existing environment and support the existing workflow. Our current workflow uses a mixture of xhost and xauth to allow xclients to connect to xservers. While "ssh -Y" may technically be an elegant solution, requiring it would break our existing tools, processes, and scripts. Simply put, any thin client solution we deploy has to support TCP connections if it is to meet our requirement of not disrupting how work is currently done.

I acknowledge that there is a security issue with TCP connections in X11, but that is an architectural issue with X11 itself and not with X2Go per se. If the developers of X2Go were to make TCP connections impossible then effectively the defined security model of X11 (as documented in places like the XSecurity and Xauth man pages) would be broken. TCP is part of how X11 works.

Once it became apparent in our testing that exporting displays didn't work as expected, the system administrator who installed it went through the configuration files and documentation looking for a solution. He couldn't find one, so he escalated it to me to look into. If we hadn't been able to find a fix it would have ruled out X2Go from further consideration, which would have been unfortunate as it is currently our leading choice for this particular need.

Hopefully the above helps persuade you that there is a need for some users to be able to continue to support the existing X11 security model (including TCP).

If you accept that point, then it seems there should be a more elegant way of enabling TCP than editing the x2gostartagent file. As someone brand new to looking at the project, files like x2goagent.options or x2goserver.conf are the obvious places I would expect to find an option to make this change.

Thanks,
Nick




On Friday, December 6, 2013 5:16 AM, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
Am 06.12.2013 13:06, schrieb Mike Gabriel:
> The default should be ,,disabled'', of course. However, I think that we
> should support people that want to use X2Go in their setup as a
> replacement for *NX*. Making something configurable and putting a big
> red warning sign above the configuration should be ok IMHO.

> Feedback?

Is there no way of assisting this user in migrating away from NX, other
than raping our codebase like that?

What's wrong with using ssh -X / ssh -Y, which was previously suggested
to the user?

Maybe some more information on what the user is trying to accomplish
would help us come up with a better solution.


-Stefan


---1593584224-1574623545-1386351855=:74486--