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 protected]> 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
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31
mail: [email protected], http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
_______________________________________________
X2Go-Dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/x2go-dev
