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>