X2Go Bug report logs -
#354
Make x2goagent listening to TCP connections configurable in x2goserver.conf
Reported by: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Date: Fri, 6 Dec 2013 11:33:02 UTC
Severity: wishlist
Tags: pending
Fixed in version 4.0.1.10
Done: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Bug is archived. No further changes may be made.
Toggle useless messages
Report forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 11:33:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
New Bug report received and forwarded. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 11:33:02 GMT) (full text, mbox, link).
Message #5 received at submit@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 12:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 12:18:02 GMT) (full text, mbox, link).
Message #10 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Stefan,
On Fr 06 Dez 2013 12:57:34 CET, Stefan Baur wrote:
> Am 06.12.2013 12:21, schrieb Mike Gabriel:
>
>> Make x2goagent listening to TCP connections configurable in
>> x2goserver.conf.
>
>> This was requested by Nick Ingegneri on x2go-user ML.
>
> IIRC, nolisten TCP was set for security reasons
> (Message-ID:
> <20120512013211.50944typ0bgbjypn@mail.das-netzwerkteam.de>, 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
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 12:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 12:18:02 GMT) (full text, mbox, link).
Message #15 received at 354@bugs.x2go.org (full text, mbox, reply):
Am 06.12.2013 12:21, schrieb Mike Gabriel:
> Make x2goagent listening to TCP connections configurable in
> x2goserver.conf.
> This was requested by Nick Ingegneri on x2go-user ML.
IIRC, nolisten TCP was set for security reasons
(Message-ID: <20120512013211.50944typ0bgbjypn@mail.das-netzwerkteam.de>,
Date: Sat, 12 May 2012 01:32:11 +0200 might trigger some memories ...).
Are we sure we want to make that option available?
-Stefan
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 12:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 12:18:03 GMT) (full text, mbox, link).
Message #20 received at 354@bugs.x2go.org (full text, mbox, reply):
Am 06.12.2013 13:06, schrieb Mike Gabriel:
>> 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
> replacement for *NX*. Making something configurable and putting a big
> red warning sign above the configuration should be ok IMHO.
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 12:18:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 12:18:03 GMT) (full text, mbox, link).
Message #25 received at 354@bugs.x2go.org (full text, mbox, reply):
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 17:48:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Nick Ingegneri <n_ingegneri@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 17:48:01 GMT) (full text, mbox, link).
Message #30 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 18:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 18:18:02 GMT) (full text, mbox, link).
Message #35 received at 354@bugs.x2go.org (full text, mbox, reply):
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Fri, 06 Dec 2013 20:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Alexander Wuerstlein <snalwuer@cip.informatik.uni-erlangen.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Fri, 06 Dec 2013 20:18:02 GMT) (full text, mbox, link).
Message #40 received at 354@bugs.x2go.org (full text, mbox, reply):
On 13-12-06 19:18, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
> Am 06.12.2013 18:44, schrieb Nick Ingegneri:
> >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.
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sat, 07 Dec 2013 20:48:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sat, 07 Dec 2013 20:48:02 GMT) (full text, mbox, link).
Message #45 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Stefan, hi Alexander,
On Fr 06 Dez 2013 20:56:00 CET, Alexander Wuerstlein wrote:
> On 13-12-06 19:18, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
>> Am 06.12.2013 18:44, schrieb Nick Ingegneri:
>> >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.
>>
>> [...]
>> 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 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...
>> 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.
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
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sat, 07 Dec 2013 21:33:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sat, 07 Dec 2013 21:33:02 GMT) (full text, mbox, link).
Message #50 received at 354@bugs.x2go.org (full text, mbox, reply):
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]
> 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).
This, this, and exactly this.
[by Alexander Wuerstlein]
>> 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.
[from Mike]
> 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?
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.
>>> 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.
>
> 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.
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 ...
> 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.
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
> switch-off in an obvious place (i.e. a conffile)?
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
> parameter for x2goserver.conf that avoids people from nastily hacking
> 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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sat, 07 Dec 2013 21:51:04 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sat, 07 Dec 2013 21:51:04 GMT) (full text, mbox, link).
Message #55 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
[Message part 2 (application/pgp-signature, inline)]
Added tag(s) wontfix.
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to 354-submit@bugs.x2go.org
.
(Sat, 07 Dec 2013 21:51:05 GMT) (full text, mbox, link).
Marked Bug as done
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to 354-submit@bugs.x2go.org
.
(Sat, 07 Dec 2013 21:51:05 GMT) (full text, mbox, link).
Notification sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug acknowledged by developer.
(Sat, 07 Dec 2013 21:51:05 GMT) (full text, mbox, link).
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sun, 08 Dec 2013 15:18:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Nick Ingegneri <n_ingegneri@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sun, 08 Dec 2013 15:18:01 GMT) (full text, mbox, link).
Message #66 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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 <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
--
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
[Message part 2 (text/html, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sun, 08 Dec 2013 19:48:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sun, 08 Dec 2013 19:48:01 GMT) (full text, mbox, link).
Message #71 received at 354@bugs.x2go.org (full text, mbox, reply):
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sun, 08 Dec 2013 20:18:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Nable 80 <nable.maininbox@googlemail.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sun, 08 Dec 2013 20:18:01 GMT) (full text, mbox, link).
Message #76 received at 354@bugs.x2go.org (full text, mbox, reply):
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 <newsgroups.mail2@stefanbaur.de>:
> 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
> _______________________________________________
> X2Go-Dev mailing list
> X2Go-Dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/x2go-dev
>
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Sun, 08 Dec 2013 20:18:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Stefan Baur <newsgroups.mail2@stefanbaur.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Sun, 08 Dec 2013 20:18:01 GMT) (full text, mbox, link).
Message #81 received at 354@bugs.x2go.org (full text, mbox, reply):
Am 08.12.2013 21:05, schrieb Nable 80:
> 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?
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
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Mon, 09 Dec 2013 08:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Mon, 09 Dec 2013 08:18:02 GMT) (full text, mbox, link).
Message #86 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hi Stefan,
On So 08 Dez 2013 21:10:57 CET, Stefan Baur wrote:
> Am 08.12.2013 21:05, schrieb Nable 80:
>> 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?
>
> 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
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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Mon, 09 Dec 2013 08:18:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Mon, 09 Dec 2013 08:18:02 GMT) (full text, mbox, link).
Message #91 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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: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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Mon, 09 Dec 2013 15:03:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Mon, 09 Dec 2013 15:03:01 GMT) (full text, mbox, link).
Message #96 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Control: reopen -1
Control: tag -1 - wontfix
Hi all,
On Mo 09 Dez 2013 09:08:29 CET, Mike Gabriel wrote:
> I will discuss this issue personally with Alex (Oleksandr Shneyder)
> 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
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
[Message part 2 (application/pgp-signature, inline)]
Bug reopened
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to 354-submit@bugs.x2go.org
.
(Mon, 09 Dec 2013 15:03:02 GMT) (full text, mbox, link).
Removed tag(s) wontfix.
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to 354-submit@bugs.x2go.org
.
(Mon, 09 Dec 2013 15:03:02 GMT) (full text, mbox, link).
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Tue, 10 Dec 2013 09:03:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Tue, 10 Dec 2013 09:03:02 GMT) (full text, mbox, link).
Message #105 received at 354@bugs.x2go.org (full text, mbox, reply):
tag #354 pending
fixed #354 4.0.1.10
thanks
Hello,
X2Go issue #354 (src:x2goserver) reported by you has been
fixed in X2Go Git. You can see the changelog below, and you can
check the diff of the fix at:
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=13ec71f
The issue will most likely be fixed in src:x2goserver (4.0.1.10).
light+love
X2Go Git Admin (on behalf of the sender of this mail)
---
commit 13ec71f7df3efae239c2dbe96a5abe9370fa7b2f
Author: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
Date: Tue Dec 10 09:36:44 2013 +0100
Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).
diff --git a/debian/changelog b/debian/changelog
index 3a54b9d..9c562e3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,7 @@ x2goserver (4.0.1.10-0x2go1) UNRELEASED; urgency=low
- x2goserver-fmbindings/Makefile: install share/applications and share/mime.
- x2goserver-printing/Makefile: create feature.d directory before installing
files into it.
+ - Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).
* Grab systemd service file from Fedora and ship it upstream.
* Add init script for RPM based distro. Taken from the Fedora
package.
Added tag(s) pending.
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to control@bugs.x2go.org
.
(Tue, 10 Dec 2013 09:03:02 GMT) (full text, mbox, link).
Marked as fixed in versions 4.0.1.10.
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to control@bugs.x2go.org
.
(Tue, 10 Dec 2013 09:03:02 GMT) (full text, mbox, link).
Message sent on
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug#354.
(Tue, 10 Dec 2013 09:03:03 GMT) (full text, mbox, link).
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Mon, 06 Jan 2014 17:30:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Mon, 06 Jan 2014 17:30:02 GMT) (full text, mbox, link).
Message #117 received at 354@bugs.x2go.org (full text, mbox, reply):
close #354
thanks
Hello,
we are very hopeful that X2Go issue #354 reported by you
has been resolved in the new release (4.0.1.10) of the
X2Go source project »src:x2goserver«.
You can view the complete changelog entry of src:x2goserver (4.0.1.10)
below, and you can use the following link to view all the code changes
between this and the last release of src:x2goserver.
http://code.x2go.org/gitweb?p=x2goserver.git;a=commitdiff;h=1a793e3d843bbeee3e597c762d9fe1d19c97baa7;hp=f26122424320ebdb563af072fc89cc03ce8bc158
If you feel that the issue has not been resolved satisfyingly, feel
free to reopen this bug report or submit a follow-up report with
further observations described based on the new released version
of src:x2goserver.
Thanks a lot for contributing to X2Go!!!
light+love
X2Go Git Admin (on behalf of the sender of this mail)
---
X2Go Component: src:x2goserver
Version: 4.0.1.10-0x2go1
Status: RELEASE
Date: Fri, 03 Jan 2014 11:34:36 +0100
Fixes: 354 355
Changes:
x2goserver (4.0.1.10-0x2go1) RELEASED; urgency=low
.
* New upstream version (4.0.1.10):
- Fix x2goresume-session. The several parameters placed into the NX options
file are expected by x2goresume-session at very specific positions. This
we broke by trying to fix the fullscreen/geometry issue in x2gostartagent.
Thanks to Harvey Eneman for tracking this down!!! (Fixes: #355).
- x2goserver-fmbindings/Makefile: install x2gofm.
- x2goserver-fmbindings/Makefile: install share/applications and share/mime.
- x2goserver-printing/Makefile: create feature.d directory before installing
files into it.
- Handle TCP listening of x2goagent in x2goagent.options. (Fixes: #354).
- Clean up Makefiles, remove commented out lines.
- Use xkb ruleset 'base' rather than xfree86 as on RHEL systems the
xfree86 symlink to base ruleset does not exist.
- Grab systemd service file from Fedora and ship it upstream.
- Provide RHEL/Fedora support in x2goserver-xsession.
- Only sanity check for existence of /etc/x2go/Xsession.d on Debian
(derived) systems.
- Provide man page for x2goserver.conf.
* x2goserver.spec:
+ Ship x2goserver.spec (RPM package definitions) in upstream project.
(Thanks to the Fedora package maintainers). File differs from the Fedora
file already.
+ Add init script for RPM based distro. Taken from the Fedora
package.
+ Clear (Fedora package) changelog.
Marked Bug as done
Request was from Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
to control@bugs.x2go.org
.
(Mon, 06 Jan 2014 17:30:05 GMT) (full text, mbox, link).
Notification sent
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug acknowledged by developer.
(Mon, 06 Jan 2014 17:30:05 GMT) (full text, mbox, link).
Message sent on
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug#354.
(Mon, 06 Jan 2014 17:30:06 GMT) (full text, mbox, link).
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Tue, 28 Jan 2014 19:45:01 GMT) (full text, mbox, link).
Acknowledgement sent
to Dustin Foudray <dfoudray@gmail.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Tue, 28 Jan 2014 19:45:01 GMT) (full text, mbox, link).
Message #129 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hello,
With the support of setting this option through x2goagent.options,
the way we previously worked around this issue no longer work's and I am
not able to make tcp X forwarding work with the new option's file setting.
Am I missing something. In the mean time is there a way we can downgrade
back to the previous server version?
--
-Dustin Foudray
[Message part 2 (text/html, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Tue, 18 Feb 2014 22:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Yahoo!!! <customer.dept@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Tue, 18 Feb 2014 22:15:02 GMT) (full text, mbox, link).
Message #134 received at 354@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/html, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Tue, 18 Feb 2014 22:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Yahoo!!! <customer.dept@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Tue, 18 Feb 2014 22:15:02 GMT) (full text, mbox, link).
Message #139 received at 354-submit@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/html, inline)]
Information forwarded
to x2go-dev@lists.berlios.de, X2Go Developers <x2go-dev@lists.berlios.de>
:
Bug#354
; Package x2goserver
.
(Tue, 18 Feb 2014 22:15:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Yahoo!!! <customer.dept@yahoo.com>
:
Extra info received and forwarded to list. Copy sent to X2Go Developers <x2go-dev@lists.berlios.de>
.
(Tue, 18 Feb 2014 22:15:03 GMT) (full text, mbox, link).
Message #144 received at 354-submit@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/html, inline)]
Message sent on
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug#354.
(Tue, 18 Feb 2014 22:15:03 GMT) (full text, mbox, link).
Message #147 received at 354-submitter@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/html, inline)]
Message sent on
to Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
:
Bug#354.
(Tue, 18 Feb 2014 22:15:03 GMT) (full text, mbox, link).
Message #150 received at 354-submitter@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/html, inline)]
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.x2go.org>
to internal_control@bugs.x2go.org
.
(Wed, 19 Mar 2014 06:24:01 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
X2Go Developers <owner@bugs.x2go.org>.
Last modified:
Wed Oct 30 12:56:25 2024;
Machine Name:
ymir.das-netzwerkteam.de
X2Go Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.