thanks

... for the answer. We just retested it today in our environment, and the
issue is still as described. Especially we did:

1) user_A starts a xfce x2go session on hostA, without starting
x2godesktopsharing.
2) 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:
- user_A starts x2godesktopsharing, but and enables access (green icon in
menu bar)
- 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>
>