Subject: Bug#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf

From: Mike Gabriel <[email-masked]>
Date: Fri, 06 Dec 2013 11:21:55 +0000

Package: x2goserver
Severity: wishlist
Debbugs-Cc:

Make x2goagent listening to TCP connections configurable in x2goserver.conf.

This was requested by Nick Ingegneri on x2go-user ML.

Mike
-- 

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

GnuPG Key ID 0x25771B31
mail: [email-masked], http://das-netzwerkteam.de

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

---

From: Mike Gabriel <[email-masked]>
Date: Fri, 06 Dec 2013 12:06:25 +0000

Hi Stefan,

On  Fr 06 Dez 2013 12:57:34 CET, Stefan Baur wrote:

> Am 06.12.2013 12:21, schrieb Mike Gabriel:
>
> IIRC, nolisten TCP was set for security reasons
> (Message-ID:  
> <[email-masked]>, Date:  
> Sat, 12 May 2012 01:32:11 +0200 might trigger some memories ...).
>
> Are we sure we want to make that option available?

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?
Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Stefan Baur <[email-masked]>
Date: Fri, 06 Dec 2013 12:57:34 +0100

IIRC, nolisten TCP was set for security reasons
(Message-ID: <[email-masked]>, 
Date: Sat, 12 May 2012 01:32:11 +0200 might trigger some memories ...).

-Stefan

---

From: Stefan Baur <[email-masked]>
Date: Fri, 06 Dec 2013 13:11:50 +0100

>> IIRC, nolisten TCP was set for security reasons
[...]
> 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

http://www.youtube.com/watch?v=tsXEToflqGs
(Can't watch videos/don't have sound while you're reading this? Go here 
for a textual description: http://tinyurl.com/3dhhzb)

-Stefan

---

From: Stefan Baur <[email-masked]>
Date: Fri, 06 Dec 2013 13:18:17 +0100

> 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

---

From: Nick Ingegneri <[email-masked]>
Date: Fri, 6 Dec 2013 09:44:15 -0800 (PST)

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 <[email-masked]> wrote:

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

-Stefan

---

From: Stefan Baur <[email-masked]>
Date: Fri, 06 Dec 2013 19:08:05 +0100

Am 06.12.2013 18:44, schrieb Nick Ingegneri:

> 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.

Well, guys, it's 2013, almost 2014, and we live in the Post-NSA-Scandal 
world. The times of using "xhost +" and not having to worry about it are 
long over. Do yourself a favor and change your scripts.

> 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.

As a side-note, I hope you're aware that those newfangled GUI thingies 
like Wayland and Mir are ditching TCP in their core design?  Just sayin' 
(I don't like them, either) - not that that comes to bite you in the 
lower back in a few years when you don't expect it.

> 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.

In my opinion, Mike is a bit too customer-friendly here by turning your 
request into a wishlist item that lets every newbie shoot him-/herself 
in the foot, security-wise, by toggling a setting in the configuration.
Sorry, but I've seen way too many people go "chmod 777 -R /*" as soon as 
something doesn't work as expected, and I'm fearing the same for an 
easily reachable option to allow TCP connections - because "xhost +" is 
the X/TCP equivalent of "chmod 777 -R /*" in the filesystem.

Of course, everybody is free to shoot him-/herself in the foot, that's 
why it's Linux - but merely leaving a "this is dangerous" note next to 
the parameter is like sticking a tag "please don't use this unless you 
know what you're doing" on a loaded 12-gauge in a room full of toddlers.

> 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).

Sorry, but you don't have me convinced that this is something anyone 
should use for a prolonged period of time.

> 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.

My understanding of the issue is: It's possible to allow TCP 
connections, and the fact that it's not easily reachable - but can be 
reached - is a Good Thing(TM).
We should leave it that way.
You can manually allow TCP connections in your environment to ease 
transition to X2Go - but by all means, go ahead and fix your scripts so 
they use ssh -X/-Y, and do that soon. And reconfigure X2Go to "nolisten 
TCP" the second you're done fixing your scripts.

-Stefan

---

From: Alexander Wuerstlein <[email-masked]>
Date: Fri, 6 Dec 2013 20:56:00 +0100

On 13-12-06 19:18, Stefan Baur <[email-masked]> wrote:
> In my opinion, Mike is a bit too customer-friendly here by turning
> your request into a wishlist item that lets every newbie shoot
> him-/herself in the foot, security-wise, by toggling a setting in
> the configuration.
> Sorry, but I've seen way too many people go "chmod 777 -R /*" as
> soon as something doesn't work as expected, and I'm fearing the same
> for an easily reachable option to allow TCP connections - because
> "xhost +" is the X/TCP equivalent of "chmod 777 -R /*" in the
> filesystem.
> 
> Of course, everybody is free to shoot him-/herself in the foot,
> that's why it's Linux - but merely leaving a "this is dangerous"
> note next to the parameter is like sticking a tag "please don't use
> this unless you know what you're doing" on a loaded 12-gauge in a
> room full of toddlers.

There is one more aspect to this: If there is such a configuration
option, then sooner or later the likes of Linux Mint will enable it by
default for all their users, leaving them wide open to the whole world,
despite all the warnings. They did that with 'xhost +'[0].

So I agree that even just having such an option hidden away somewhere
would be very very bad. It needs to be hard and a lot of work to break
security or somebody will do it by default and deploy it on a wide
scale.

Ciao,

Alexander Wuerstlein.

[0] http://forums.linuxmint.com/viewtopic.php?f=90&t=106520

---

From: Mike Gabriel <[email-masked]>
Date: Sat, 07 Dec 2013 20:47:59 +0000

Hi Stefan, hi Alexander,

> [0] http://forums.linuxmint.com/viewtopic.php?f=90&t=106520

 From a security point of view: is there really a severe difference in  
having to edit x2gostartagent or vs. x2goserver.conf as root to enable  
TCP listening for x2goagent? If people want to deploy X2Go and need  
TCP enabled they will do that anyway. You do not have to rebuild some  
binary to make that happen even, you just have to create a custom copy  
of x2gostartagent in /usr/local/bin.

@Nick: The above may very well be your workaround...

>> him-/herself in the foot, security-wise, by toggling a setting in

My current focus is to spread X2Go, get more people interested in X2Go  
and get more people interested in developing / financing X2Go. If I  
here of a use case that involves hundreds of users, then I am open to  
supporting that use case one way or another. I don't think making  
TCP-listening configurable is a security problem. Once you enable that  
option, you should be aware of what you are doing. For sure.

The Linux Mint argument does not really count to me, either. As a  
package maintainer of a linux distribution, I can do anything patchy  
to the upstream code I like. People with the Linux Mint attitude may  
very easily patch x2gostartagent and ship a TCP-listening X2Go Server  
by default in their package archive. Wouldn't it make more sense,  
having that option configurable from the start then and providing the  
switch-off in an obvious place (i.e. a conffile)?

My point is: if you want to enable TCP listening of x2goagent, you  
have to switch one line in x2gostartagent. What I propose is a config  
parameter for x2goserver.conf that avoids people from nastily hacking  
x2gostartagent. I know several setups in intranet where display  
managers and X-servers run in TCP listen mode and for the local  
network that is ok and wanted. Of course for X2Go this should not be  
the default (that's why we closed down TCP listening earlier when it  
was still enabled by accident).

And Nick, I also think that you should seriously consider looking at  
the security aspects of your current IT setup. It seems quite hackable  
and you should really be sure that all of your staff members are  
really good friends (which normally is not the case for everyone at  
$WORK).

Greets,
Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Stefan Baur <[email-masked]>
Date: Sat, 07 Dec 2013 22:30:17 +0100

Am 07.12.2013 21:47, schrieb Mike Gabriel:

[copying the last paragraph of your mail to the top, b/c this is the 
most important statement of it]
 > the security aspects of your current IT setup. It seems quite
 > hackable and you should really be sure that all of your staff
 > members are really good friends (which normally is not the case
 > for everyone at $WORK).

This, this, and exactly this.

[by Alexander Wuerstlein]
>> security or somebody will do it by default and deploy it on a wide

[from Mike]
> TCP listening for x2goagent?

Yes, there is. Putting it in the config file is convenient for the 
security-ignorant folks. Disabling security features should never be 
convenient.

 > If people want to deploy X2Go and need TCP
> enabled they will do that anyway. You do not have to rebuild some binary
> to make that happen even, you just have to create a custom copy of
> x2gostartagent in /usr/local/bin.

And exactly that means extra work. Most security-ignorant folks are 
security-ignorant because they are lazy, they just don't want to bother 
with it.
A config file remains in place during package upgrades.
With x2gostartagent, they'll have to make sure that their copy in 
/usr/local/bin gets pulled (And we should make it hard for them, by 
specifying /usr/bin/x2gostartagent instead of x2gostartagent without a 
path), or they have to change/patch /usr/bin/x2gostartagent with every 
new package version.

This means work. This means paying attention. Things that such folks 
don't like. In fact, if we could, we should make disabling security on 
X2Go a harder and more complex task than re-writing all those insecure 
scripts the user might have. Sadly, we can't.

> @Nick: The above may very well be your workaround...

And indeed it is, for a short-lived migration path.

> and get more people interested in developing / financing X2Go. If I here
> of a use case that involves hundreds of users, then I am open to

I'm saying it again, you're being too customer-friendly. In this 
particular case, the issue can be fixed by locally patching 
x2gostartagent. With more obscure stuff, you should tell them to 
contract you or Alex for a forked x2go package and have them pay for the 
B**ls**t they want. That way, we don't pollute our main codebase with 
it, plus you get some extra cash.

Man, where are my pills, I don't want to go into full Theo de Raadt mode ...

> package maintainer of a linux distribution, I can do anything patchy to
> the upstream code I like. People with the Linux Mint attitude may very
> easily patch x2gostartagent and ship a TCP-listening X2Go Server by
> default in their package archive.

See above, it is extra work for them, an extra file outside the config 
tree that they have to monitor for changes, etc. While we can't stop 
them, we can at least make it hard for them to follow through with such 
a plan.

 > Wouldn't it make more sense, having
> that option configurable from the start then and providing the

No. Just no.

> My point is: if you want to enable TCP listening of x2goagent, you have
> to switch one line in x2gostartagent. What I propose is a config
> x2gostartagent.

Again, those who know what they are doing are already able to make the 
change, and should realize the consequences (having to look for changes 
in x2gostartagent with every new release).

Those who do not know what they are doing should not be given access to 
the setting.

There's a reason why you need licenses for firearms, cars, airplanes, 
etc. - and this is the software equivalent.
If one has proven enough coding proficiency to have located the code 
part in x2gostartagent, one is worthy of being allowed to change it on 
one's own.
If you have to ask here, you should either listen to the more 
experienced folks telling you not to change it, or pay one of the core 
developers for a fork, that's my opinion (and not being a core developer 
myself, flames like "you're a greedy a**h**e that thinks of X2Go users 
as cash cows ready for milking" directed at me are outright silly, so - 
shove them, folks).

-Stefan

---

From: Mike Gabriel <[email-masked]>
Date: Sat, 07 Dec 2013 21:50:54 +0000

Control: tag -1 wontfix
Control: close -1

Hi Stefan,

> 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
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: [email-masked] (X2Go Bug Tracking System)
Date: Sat, 07 Dec 2013 21:51:05 +0000

This is an automatic notification regarding your Bug report
which was filed against the x2goserver package:

#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf

It has been closed by Mike Gabriel <[email-masked]>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Mike Gabriel <[email-masked]> by
replying to this email.

-- 
354: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=354
X2Go Bug Tracking System
Contact [email-masked] with problems

Subject: Re: [X2Go-Dev] Bug#354: Bug#354: Make x2goagent listening to TCP connections configurable in x2goserver.conf
From: Mike Gabriel <[email-masked]>
To: Stefan Baur <[email-masked]>
Cc: Alexander Wuerstlein <[email-masked]>, [email-masked], Nick Ingegneri <[email-masked]>
Date: Sat, 07 Dec 2013 21:50:54 +0000

Control: tag -1 wontfix
Control: close -1

Hi Stefan,

Okokokok... heard!

Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

Subject: Make x2goagent listening to TCP connections configurable in x2goserver.conf
From: Mike Gabriel <[email-masked]>
To: [email-masked]
Cc: Nick Ingegneri <[email-masked]>
Date: Fri, 06 Dec 2013 11:21:55 +0000

Package: x2goserver
Severity: wishlist
Debbugs-Cc:

Mike
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Nick Ingegneri <[email-masked]>
Date: Sun, 8 Dec 2013 07:13:02 -0800 (PST)

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

On Saturday, December 7, 2013 2:51 PM, Mike Gabriel <[email-masked]> wrote:
 
Control: tag -1 wontfix
Control: close -1

Hi Stefan,

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
-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Stefan Baur <[email-masked]>
Date: Sun, 08 Dec 2013 20:35:14 +0100

Am 08.12.2013 16:13, schrieb Nick Ingegneri:
> 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.

[long blahblah snipped]

If you believe Xauth Cookies alone will protect you from nastiness, 
think again:
http://www.hackinglinuxexposed.com/articles/20040608.html - "Abusing X11 
for fun and passwords."

All the nastiness shown in that write-up works *with* .Xauthority in place.
And this was published in 2004, so every script kiddie, every 
pimple-faced youth among your trainees, every disgruntled employee knows 
about this. (And so does the NSA.)

Seriously, I've been in the IT Security business for quite a few years 
*ahem ahem* - and the real enemy usually isn't some obscure Chinese 
hacker, it's an employee, either a lazy and careless one or a malicious 
one that has been turned over by a competitor. So do not trust anyone 
and anything on your network. Encrypt even your internal traffic.
I've even seen reports of power plugs with surge protectors containing 
Network sniffers. So the spying device has unlimited power supply and 
sits right in your network, logging all your traffic and sending it out 
either via innocuous http requests or via a seperate WiFi network.

And please, do not fool yourself into thinking "but we don't have 
anything to hide". Yes, you have. We all have. Unless you see "1984" as 
an instruction manual.

-Stefan

---

From: Nable 80 <[email-masked]>
Date: Mon, 9 Dec 2013 00:05:21 +0400

Thanks a lot for this interesting discussion.

Although I should comment this thing from the linked article: it
begins with the following words:
> log into the victim's desktop, become root
It's too obvious that with root one can do almost anything, not only
grab X sessions.
So, you article is not a proof of X11 insecurity (after all, we know
that it's not secure, but example is not good), just a howto for root
usage.
One should notice that without root ( who would give root access to
generic employee? except (possibly) on his workstation) you still
cannot access other users' cookies (except cases when one have too
wide permissions or known vulnerabilitites with privelege escalation),
so you cannot grab their X sessions, can you?

2013/12/8, Stefan Baur <[email-masked]>:
> _______________________________________________
> X2Go-Dev mailing list
> [email-masked]
> https://lists.berlios.de/mailman/listinfo/x2go-dev
>

---

From: Stefan Baur <[email-masked]>
Date: Sun, 08 Dec 2013 21:10:57 +0100

> cannot access other users' cookies (except cases when one have too
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> wide permissions or known vulnerabilitites with privelege escalation),
   ^^^^^^^^^^^^^^^^
> so you cannot grab their X sessions, can you?

And here we are again at "Hey, $FOO doesn't work, I'll just do chmod -R 
777 * and see if that makes it work."

Plus, the rogue employee may as well be the admin, and thus have root 
rights on the machine where you're logged in.

-Stefan

---

From: Mike Gabriel <[email-masked]>
Date: Mon, 09 Dec 2013 08:02:56 +0000

Hi Stefan,

On  So 08 Dez 2013 21:10:57 CET, Stefan Baur wrote:

> And here we are again at "Hey, $FOO doesn't work, I'll just do chmod  
> -R 777 * and see if that makes it work."
>
> Plus, the rogue employee may as well be the admin, and thus have  
> root rights on the machine where you're logged in.
>
> -Stefan

For X2Go we must assume that the root user is a trustworthy person.  
Otherwise we are completely lost.

Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Mike Gabriel <[email-masked]>
Date: Mon, 09 Dec 2013 08:08:29 +0000

Hi Nick,

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

>> On Saturday, December 7, 2013 2:51 PM, Mike Gabriel  
>> <[email-masked]> wrote:
>>
>> Control: tag -1 wontfix
>> Control: close -1
>>
>> Hi Stefan,
>>
>>  /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

> 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:
>
> 2: Automated processes, with no user involvement, launch a program  
> on a randomly chosen system (let's say it is system204).
> 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

GnuPG Key ID 0x25771B31

freeBusy:

---

From: Mike Gabriel <[email-masked]>
Date: Mon, 09 Dec 2013 14:51:04 +0000

Control: reopen -1
Control: tag -1 - wontfix

Hi all,

> and the two of use will then decide how to procede here.

I have talked to Alex. We will implement a config option that enables  
TCP listening of x2goagent. There will be a big red sign in the config  
and the default will be to TCP-nolisten.

light+love
Mike

-- 

DAS-NETZWERKTEAM

GnuPG Key ID 0x25771B31

freeBusy: