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:24Personally, 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.xf...