Package: x2goserver Version: 4.0.1.6 Severity: critical
Hi,
I just noticed that x2goserver allows to connect to ALL running X sessions on the target machine, using "connect to local desktop". These might be logged in local users, or NX sessions which were not terminated correctly. This is especially worse in the latter case, as the screen is not locked here, normally.
This is a HUGE security leak, as now all users are able to access data of the other users, and hinder them from working by manipulating current sessions.
Normal remote desktop software should BLOCK such access by default, and only allow it when the user explicitly requested it or configured it so.
control: tag -1 moreinfo control: tag -1 not-a-bug control: tag -1 wontfix
On Mi 07 Aug 2013 07:36:18 CEST David Fuhrmann wrote:
I just noticed that x2goserver allows to connect to ALL running X
sessions on the target machine, using "connect to local desktop".
These might be logged in local users, or NX sessions which were not
terminated correctly. This is especially worse in the latter case,
as the screen is not locked here, normally.This is a HUGE security leak, as now all users are able to access
data of the other users, and hinder them from working by
manipulating current sessions.Normal remote desktop software should BLOCK such access by default,
and only allow it when the user explicitly requested it or
configured it so.
I just tested this to be really sure that this is a not-a-bug report...
What you describe only works for the same login!!!! So if my user
(sunweaver) logs in locally to an X-Session and ,,sunweaver'' then
connects via X2Go to connect to a local X session then I can access my
__own__ local X sessions.
However, I cannot access other users' sessions unless they grant
access via the X2Go Desktop Sharing utility.
Please re-test and re-confirm or post a message that states that the
mistake was on your part.
Thanks+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.xf...
thanks
... for the answer. We just retested it today in our environment, and the issue is still as described. Especially we did:
- user_A starts a xfce x2go session on hostA, without starting x2godesktopsharing.
- user_B logs in at hostA, using "connect to local desktop. It sees a X session under its own user name, and a port. user_B can click on "full access" and gets access to the session.
Second test:
- user_A starts x2godesktopsharing, but leave the default setting (do not allow access, with cross).
- user_B sees same behaviour as described above
Third test: menu bar)
- user_A starts x2godesktopsharing, but and enables access (green icon in
- user_B now sees two sessions in the session list: one with his own user name, one with user_As user name. Both have the same port. If user_B selects the one which has user_A as its name, he can only connect to view, and eventually, this connection gets refused. (In the mean time, user_A sees a question dialog asking user_B for access in the session.) But still, user_B sees a session with his own name, and can connect to it and gets full access to the xfce session started by user_A.
So in summary: The x2godesktopsharing has no effect at all when it should block all accesses, and only works partly when it should allow individual access.
In our environment, every machine has the same logins provided by an LDAP server. I will retest at home to see how it behaves with normal local users.
With best regards, David
2013/8/7 Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
control: tag -1 moreinfo control: tag -1 not-a-bug control: tag -1 wontfix
On Mi 07 Aug 2013 07:36:18 CEST David Fuhrmann wrote:
I just noticed that x2goserver allows to connect to ALL running X
sessions on the target machine, using "connect to local desktop". These might be logged in local users, or NX sessions which were not terminated correctly. This is especially worse in the latter case, as the screen is not locked here, normally.
This is a HUGE security leak, as now all users are able to access data of the other users, and hinder them from working by manipulating current sessions.
Normal remote desktop software should BLOCK such access by default, and only allow it when the user explicitly requested it or configured it so.
I just tested this to be really sure that this is a not-a-bug report...
What you describe only works for the same login!!!! So if my user (sunweaver) logs in locally to an X-Session and ,,sunweaver'' then connects via X2Go to connect to a local X session then I can access my __own__ local X sessions.
However, I cannot access other users' sessions unless they grant access via the X2Go Desktop Sharing utility.
Please re-test and re-confirm or post a message that states that the mistake was on your part.
Thanks+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<mike.gabriel@das-netzwerkteam.de>, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-** netzwerkteam.de.xfb<https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb>
control: tag -1 - wontfix control: tag -1 - not-a-bug
Hi David,
On Mi 07 Aug 2013 13:54:14 CEST David Fuhrmann wrote:
thanks
... for the answer. We just retested it today in our environment, and the issue is still as described. Especially we did:
- user_A starts a xfce x2go session on hostA, without starting x2godesktopsharing.
- user_B logs in at hostA, using "connect to local desktop. It sees a X session under its own user name, and a port. user_B can click on "full access" and gets access to the session.
Second test:
- user_A starts x2godesktopsharing, but leave the default setting (do not allow access, with cross).
- user_B sees same behaviour as described above
Third test: menu bar)
- user_A starts x2godesktopsharing, but and enables access (green icon in
- user_B now sees two sessions in the session list: one with his own user name, one with user_As user name. Both have the same port. If user_B selects the one which has user_A as its name, he can only connect to view, and eventually, this connection gets refused. (In the mean time, user_A sees a question dialog asking user_B for access in the session.) But still, user_B sees a session with his own name, and can connect to it and gets full access to the xfce session started by user_A.
So in summary: The x2godesktopsharing has no effect at all when it should block all accesses, and only works partly when it should allow individual access.
In our environment, every machine has the same logins provided by an LDAP server. I will retest at home to see how it behaves with normal local users.
Ok, thanks for re-testing. I undo the taggings earlier made on this
issue. This is indeed a big issue that needs immediate fixing!!!
Next question: what distro are you on. I tested on Debian and it
worked flawlessly. Do you have any chance to test on Debian or Ubuntu
(if you are on some RPM based distro)?
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.xf...
Hi,
We are using a debian-based linux mint, and installed the server from the debian 7 repository IIRC.
I just tested at home on Ubuntu 10.04, and here it works fine. I think this might be some configuration issue.
Best, David
Am 07.08.2013 um 16:02 schrieb Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
control: tag -1 - wontfix control: tag -1 - not-a-bug
Hi David,
On Mi 07 Aug 2013 13:54:14 CEST David Fuhrmann wrote:
thanks
... for the answer. We just retested it today in our environment, and the issue is still as described. Especially we did:
- user_A starts a xfce x2go session on hostA, without starting x2godesktopsharing.
- user_B logs in at hostA, using "connect to local desktop. It sees a X session under its own user name, and a port. user_B can click on "full access" and gets access to the session.
Second test:
- user_A starts x2godesktopsharing, but leave the default setting (do not allow access, with cross).
- user_B sees same behaviour as described above
Third test: menu bar)
- user_A starts x2godesktopsharing, but and enables access (green icon in
- user_B now sees two sessions in the session list: one with his own user name, one with user_As user name. Both have the same port. If user_B selects the one which has user_A as its name, he can only connect to view, and eventually, this connection gets refused. (In the mean time, user_A sees a question dialog asking user_B for access in the session.) But still, user_B sees a session with his own name, and can connect to it and gets full access to the xfce session started by user_A.
So in summary: The x2godesktopsharing has no effect at all when it should block all accesses, and only works partly when it should allow individual access.
In our environment, every machine has the same logins provided by an LDAP server. I will retest at home to see how it behaves with normal local users.
Ok, thanks for re-testing. I undo the taggings earlier made on this issue. This is indeed a big issue that needs immediate fixing!!!
Next question: what distro are you on. I tested on Debian and it worked flawlessly. Do you have any chance to test on Debian or Ubuntu (if you are on some RPM based distro)?
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.xf...
Hi,
To rule out some specific configuration issue in our current system, I installed a fresh linux mint inside a virtual machine and was able to confirm the issues.
You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.
With best regards, David
Am 07.08.2013 um 17:56 schrieb David Fuhrmann <fuhrmann_mail@web.de>:
Hi,
We are using a debian-based linux mint, and installed the server from the debian 7 repository IIRC.
I just tested at home on Ubuntu 10.04, and here it works fine. I think this might be some configuration issue.
Best, David
Am 07.08.2013 um 16:02 schrieb Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
control: tag -1 - wontfix control: tag -1 - not-a-bug
Hi David,
On Mi 07 Aug 2013 13:54:14 CEST David Fuhrmann wrote:
thanks
... for the answer. We just retested it today in our environment, and the issue is still as described. Especially we did:
- user_A starts a xfce x2go session on hostA, without starting x2godesktopsharing.
- user_B logs in at hostA, using "connect to local desktop. It sees a X session under its own user name, and a port. user_B can click on "full access" and gets access to the session.
Second test:
- user_A starts x2godesktopsharing, but leave the default setting (do not allow access, with cross).
- user_B sees same behaviour as described above
Third test: menu bar)
- user_A starts x2godesktopsharing, but and enables access (green icon in
- user_B now sees two sessions in the session list: one with his own user name, one with user_As user name. Both have the same port. If user_B selects the one which has user_A as its name, he can only connect to view, and eventually, this connection gets refused. (In the mean time, user_A sees a question dialog asking user_B for access in the session.) But still, user_B sees a session with his own name, and can connect to it and gets full access to the xfce session started by user_A.
So in summary: The x2godesktopsharing has no effect at all when it should block all accesses, and only works partly when it should allow individual access.
In our environment, every machine has the same logins provided by an LDAP server. I will retest at home to see how it behaves with normal local users.
Ok, thanks for re-testing. I undo the taggings earlier made on this issue. This is indeed a big issue that needs immediate fixing!!!
Next question: what distro are you on. I tested on Debian and it worked flawlessly. Do you have any chance to test on Debian or Ubuntu (if you are on some RPM based distro)?
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.xf...
Hi David,
On Mi 07 Aug 2013 20:10:44 CEST David Fuhrmann wrote:
To rule out some specific configuration issue in our current system,
I installed a fresh linux mint inside a virtual machine and was able
to confirm the issues.You should be able to reproduce it easily by doing the same. Choose
Linux Mint debian edition, 64 Bit, Mate package and install
x2goserver following your instructions for debian 7.
What is the primary GID of users on Linux Mint. Do they follow the pattern
foo:foo bar:bar sunweaver:sunweaver
or is there a group that all users get crushed in with there primary
GIDs, like
foo:users bar:users sunweaver:users
???
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...
Am 07.08.2013 um 21:22 schrieb Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
Hi David,
On Mi 07 Aug 2013 20:10:44 CEST David Fuhrmann wrote:
To rule out some specific configuration issue in our current system, I installed a fresh linux mint inside a virtual machine and was able to confirm the issues.
You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.
What is the primary GID of users on Linux Mint. Do they follow the pattern
foo:foo bar:bar sunweaver:sunweaver
or is there a group that all users get crushed in with there primary GIDs, like
foo:users bar:users sunweaver:users
In a fresh linux mint system, the first one. In our production environment, the latter one.
Any news regarding this bug?
Am 07.08.2013 um 21:56 schrieb David Fuhrmann <fuhrmann_mail@web.de>:
Am 07.08.2013 um 21:22 schrieb Mike Gabriel <mike.gabriel@das-netzwerkteam.de>:
Hi David,
On Mi 07 Aug 2013 20:10:44 CEST David Fuhrmann wrote:
To rule out some specific configuration issue in our current system, I installed a fresh linux mint inside a virtual machine and was able to confirm the issues.
You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.
What is the primary GID of users on Linux Mint. Do they follow the pattern
foo:foo bar:bar sunweaver:sunweaver
or is there a group that all users get crushed in with there primary GIDs, like
foo:users bar:users sunweaver:users
In a fresh linux mint system, the first one. In our production environment, the latter one.
Hi David,
On Sa 17 Aug 2013 09:03:21 CEST David Fuhrmann wrote:
Any news regarding this bug?
I have set up a test VM for this issue today and I can absolute
confirm what you report.
I will investigate on that further today/tomorrow, and I am quite sure
of being able to exploit this without X2Go as well.
My guess is a mis-configuration in Linux mint around the local X-Server.
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...
Please look at message
From: Fred Her. <x2go@edhil.net> Date: Fri, 16 Aug 2013 14:47:40 +0000 (UTC) Message-ID: <loom.20130816T163241-4@post.gmane.org>
which I just forwarded to the bugtracker (seems it went to the list, but not the bugtracker).
Looks like the root cause for the problem has been found and it is indeed a Linux Mint configuration stupidity.
-Stefan
Am 17.08.2013 17:28, schrieb Mike Gabriel:
Hi David,
On Sa 17 Aug 2013 09:03:21 CEST David Fuhrmann wrote:
Any news regarding this bug?
I have set up a test VM for this issue today and I can absolute confirm what you report.
I will investigate on that further today/tomorrow, and I am quite sure of being able to exploit this without X2Go as well.
My guess is a mis-configuration in Linux mint around the local X-Server.
Mike
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
David Fuhrmann <fuhrmann_mail <at> web.de> writes:
Hi,
To rule out some specific configuration issue in our current system, I
installed a fresh linux mint inside a
virtual machine and was able to confirm the issues.
You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.
I performed the test on the same configuration, and can confirm this issue:
On a fresh linux mint issue, Ubuntu edition, 64bits, MATE package.
x2go package installed :
ii x2goserver 4.0.1.6-0~712~raring1 amd64 ii x2goserver-extensions 4.0.1.6-0~712~raring1 all ii x2goserver-xsession 4.0.1.6-0~712~raring1 all
userA creates a session with a custom desktop (x-session-manager) and connect. Then close the session window (but do not disconnect)
UserB creates a session with "connect to Local Desktop" and log in using his own login and ssh password
UserB can connect to UserA desktop with full access.
As a workaround, ss there any x2goserver.conf parameters that could be used to disable the Local Desktop access?
Actually, this is not an x2go issue, this is a linux mint issue : by default, there is a "xhost +" command launched at session startup for all users.
If you type "xhost - ", then you should see the normal behavior again : userB will get a "no desktop found" message if he try to connect to the x2go host.
So, the workaround is to remove the "xhost +" command in the Control Panel > Startup Applications for each user,
or completely remove the /etc/xdg/autostart/mint-xhost-plus.desktop (but this could come back if the package ubuntu-system-adjustments is updated)
or change this file to:
[Desktop Entry] Encoding=UTF-8 Version=1.0 Name=Xhost + Exec=xhost + Terminal=false Type=Application StartupNotify=false Terminal=false X-MATE-Autostart-enabled=false Hidden=true
note to x2go packages maintainers: Maybe this should be an option to check/disable when the x2goserver package is installed?
Or maybe a warning should be issued if "xhost" is set to + when a user connect?
Looks like this info wasn't forwared to the bugtracker, forwarding manually.
-------- Original-Nachricht -------- Betreff: [X2Go-Dev] Bug#287: x2goserver allows to connect to ALL X server sessions by default Datum: Fri, 16 Aug 2013 14:47:40 +0000 (UTC) Von: Fred Her. <x2go@edhil.net> Antwort an: x2go-dev@lists.berlios.de An: x2go-dev@lists.berlios.de
Actually, this is not an x2go issue, this is a linux mint issue : by default, there is a "xhost +" command launched at session startup for all users.
If you type "xhost - ", then you should see the normal behavior again : userB will get a "no desktop found" message if he try to connect to the x2go host.
So, the workaround is to remove the "xhost +" command in the Control Panel > Startup Applications for each user,
or completely remove the /etc/xdg/autostart/mint-xhost-plus.desktop (but this could come back if the package ubuntu-system-adjustments is updated)
or change this file to:
[Desktop Entry] Encoding=UTF-8 Version=1.0 Name=Xhost + Exec=xhost + Terminal=false Type=Application StartupNotify=false Terminal=false X-MATE-Autostart-enabled=false Hidden=true
note to x2go packages maintainers: Maybe this should be an option to check/disable when the x2goserver package is installed?
Or maybe a warning should be issued if "xhost" is set to + when a user connect?
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
title #287 Linux Mint desktops configured too insecurely for multi-user mode tag #287 confirmed tag #287 wontfix close #287 thanks
Hi all,
On Sa 17 Aug 2013 17:35:24 CEST Stefan Baur wrote:
Actually, this is not an x2go issue, this is a linux mint issue : by default, there is a "xhost +" command launched at session startup for all users.
If you type "xhost - ", then you should see the normal behavior again : userB will get a "no desktop found" message if he try to connect to the x2go host.
So, the workaround is to remove the "xhost +" command in the Control Panel > Startup Applications for each user,
or completely remove the /etc/xdg/autostart/mint-xhost-plus.desktop (but this could come back if the package ubuntu-system-adjustments is updated)
or change this file to:
[Desktop Entry] Encoding=UTF-8 Version=1.0 Name=Xhost + Exec=xhost + Terminal=false Type=Application StartupNotify=false Terminal=false X-MATE-Autostart-enabled=false Hidden=true
We (David and I) just figured out the same... (what a race
condition...). Thanks! What a security leakage if people start using
Linux Mint in multi-user operation mode (like with X2Go or locally or
with LTSP).
With xhost + for every user you can launch applications on other
people's desktops and also read out their clipboards' contents.
/me rarely has to puke at other people's work, but this time... Well, yes.
note to x2go packages maintainers: Maybe this should be an option to check/disable when the x2goserver package is installed?
No! We won't work around such grave issues in distributions or in
other packages. This needs to be immediately fixed in Linux Mint
upstream.
Or maybe a warning should be issued if "xhost" is set to + when a user connect?
Nope! In default setups no other distro evokes xhost + on session
startup. This is just insane!!! So we ignore this issue in X2Go
upstream completely.
Stay away from Linux Mint with X2Go (or actually at all) till this has
been fixed in Mint.
light+love, Mike
PS: quote me freely if needed...
--
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...
Processing commands for control@bugs.x2go.org:
title #287 Linux Mint desktops configured too insecurely for multi-user mode Unknown command or malformed arguments to command. tag #287 confirmed Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Added tag(s) confirmed. tag #287 wontfix Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Added tag(s) wontfix. close #287 Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Marked Bug as done thanks Stopping processing here.
Please contact me if you need assistance.
287: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=287 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
Am 17.08.2013 20:42, schrieb Mike Gabriel:
Or maybe a warning should be issued if "xhost" is set to + when a user connect?
Nope! In default setups no other distro evokes xhost + on session startup. This is just insane!!! So we ignore this issue in X2Go upstream completely.
I'd still vote for adding a check + warning to X2Go. Even if this brain-dead setup that is rolled out by Linux Mint isn't the default in other distros, someone might set "xhost +" somewhere, sometime, and totally forget about it. A reminder/warning "Hey, you're running X2Go on a host that hast 'xhost +' set, this is a really bad idea", followed by a short explanation, would make sense, IMO.
-Stefan
Hi Stefan,
On Sa 17 Aug 2013 21:09:02 CEST Stefan Baur wrote:
Am 17.08.2013 20:42, schrieb Mike Gabriel:
Or maybe a warning should be issued if "xhost" is set to + when a user connect?
Nope! In default setups no other distro evokes xhost + on session startup. This is just insane!!! So we ignore this issue in X2Go upstream completely.
I'd still vote for adding a check + warning to X2Go. Even if this brain-dead setup that is rolled out by Linux Mint isn't
the default in other distros, someone might set "xhost +" somewhere,
sometime, and totally forget about it. A reminder/warning "Hey, you're running X2Go on a host that hast
'xhost +' set, this is a really bad idea", followed by a short
explanation, would make sense, IMO.
Any patch is welcome (on the other hand). But do not introduce a
daemon that checks .Xauthority every five seconds ;-)...
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...
Am 17.08.2013 21:23, schrieb Mike Gabriel:
I'd still vote for adding a check + warning to X2Go. Even if this brain-dead setup that is rolled out by Linux Mint isn't the default in other distros, someone might set "xhost +" somewhere, sometime, and totally forget about it. A reminder/warning "Hey, you're running X2Go on a host that hast 'xhost +' set, this is a really bad idea", followed by a short explanation, would make sense, IMO.
Any patch is welcome (on the other hand). But do not introduce a daemon that checks .Xauthority every five seconds ;-)...
/me now silently deletes his draft that contained "while true" and "sleep 5"
Seriously, you know coding isn't my strong side. So all I can do is suggest that someone adds this feature. My suggestion would be to check it either during installation/upgrade of the x2go server package, or each time a user connects. The latter would make more sense, IMHO, but I don't know what the performance penalty would be.
-Stefan
Hi Stefan,
On Sa 17 Aug 2013 21:27:38 CEST Stefan Baur wrote:
Seriously, you know coding isn't my strong side. So all I can do is
suggest that someone adds this feature. My suggestion would be to
check it either during installation/upgrade of the x2go server
package, or each time a user connects. The latter would make more sense, IMHO, but I don't know what the
performance penalty would be.
I still do not believe you about the coding not being your thing... If
one can customize X2Go like you did, you surely have the knowledge
base for looking into coding...
;-) 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...
Am 17.08.2013 22:22, schrieb Mike Gabriel:
If one can customize X2Go like you did, you surely have the knowledge base for looking into coding...
Dammit, Mike, I'm a Sysadmin, not a Coder!
On 2013-08-17 22:26, Stefan Baur wrote:
Am 17.08.2013 22:22, schrieb Mike Gabriel:
If one can customize X2Go like you did, you surely have the knowledge base for looking into coding...
Dammit, Mike, I'm a Sysadmin, not a Coder!
Does not free you from writing a bit of Bash/Perl ;) . If you provide Mike with a snippet that outputs "WARNING: XHOST is set to +", I'm sure he'll C&P it into the appropriate startup stript. That way it will at least end up in some log - and mike saves a lot of time looking into this....
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Looks like this info wasn't sent to the bugtracker, forwarding manually.
-------- Original-Nachricht -------- Betreff: Re: [X2Go-Dev] Bug#287: Bug#287: x2goserver allows to connect to ALL X server sessions by default Datum: Fri, 16 Aug 2013 13:41:34 +0000 (UTC) Von: Fred Her. <x2go@edhil.net> Antwort an: x2go-dev@lists.berlios.de An: x2go-dev@lists.berlios.de
David Fuhrmann <fuhrmann_mail <at> web.de> writes:
Hi,
To rule out some specific configuration issue in our current system, I
installed a fresh linux mint inside a
virtual machine and was able to confirm the issues.
You should be able to reproduce it easily by doing the same. Choose Linux Mint debian edition, 64 Bit, Mate package and install x2goserver following your instructions for debian 7.
I performed the test on the same configuration, and can confirm this issue:
On a fresh linux mint issue, Ubuntu edition, 64bits, MATE package.
x2go package installed :
ii x2goserver 4.0.1.6-0~712~raring1 amd64 ii x2goserver-extensions 4.0.1.6-0~712~raring1 all ii x2goserver-xsession 4.0.1.6-0~712~raring1 all
userA creates a session with a custom desktop (x-session-manager) and connect. Then close the session window (but do not disconnect)
UserB creates a session with "connect to Local Desktop" and log in using his own login and ssh password
UserB can connect to UserA desktop with full access.
As a workaround, ss there any x2goserver.conf parameters that could be used to disable the Local Desktop access?
X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
Processing control commands:
tag -1 moreinfo Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Added tag(s) moreinfo. tag -1 not-a-bug Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Added tag(s) not-a-bug. tag -1 wontfix Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Added tag(s) wontfix.
-- 287: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=287 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
Processing control commands:
tag -1 - wontfix Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Removed tag(s) wontfix. tag -1 - not-a-bug Bug #287 [x2goserver] x2goserver allows to connect to ALL X server sessions by default Removed tag(s) not-a-bug.
-- 287: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=287 X2Go Bug Tracking System Contact owner@bugs.x2go.org with problems
-
David Fuhrmann -
Fred Her. -
Mike Gabriel -
Moritz Struebe -
owner＠bugs.x2go.org -
Stefan Baur