Hi Nick, On So 08 Dez 2013 16:13:02 CET, Nick Ingegneri wrote: >> On Saturday, December 7, 2013 2:51 PM, Mike Gabriel >> 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