Xpra: Ticket #576: the --display seems to not exist in the client, thus implement --target-session

This patch is a draft that enable to select a session through a proxy.

the documented --display seems to not exist, thus I implemented one here

Best regards



Fri, 23 May 2014 20:42:22 GMT - Benoit Gschwind: attachment set

patch that implement --target-session


Sat, 24 May 2014 14:13:16 GMT - Benoit Gschwind:

/!\ Author WARNING this patch is unsecure with PAM auth /!\

use with caution


Mon, 26 May 2014 09:58:35 GMT - Antoine Martin: owner changed

Here are some of the issues we need to think about:


Mon, 26 May 2014 11:44:49 GMT - Benoit Gschwind:

Replying to totaam:

Here are some of the issues we need to think about:


When I created this patch I thought about ssh, ssh allow any tunnel by default to any host. I thought it is a question of setup (may be xpra proxy could have a white list or iptables and so on. This is also important to note that proxy authenticate the user which limit the abusive use of the proxy, and that make an udge difference from HTTP proxy.


The scenario is an easy setup, user has no complicated setup to do. Another case is if you have several computer, and add a new one, no proxy update is required.
I also thought about another way by using a mapping between virtual_host -> real host, but this make more complicated setup with no real benefits. (see ssh tunnel comments)


I will look at those ticket, I agree this part of the patch his out of scope of this ticket.


If I did it this is probably because I got an error, but while I'm not totally aware of every thing happening within xpra, I may made a bad command line.


Yes

I will review this patch, but I would like to do it after #172 is resolved


Mon, 26 May 2014 12:51:41 GMT - Antoine Martin:

ssh allow any tunnel by default to any host


It is usually the case, but not necessarily so: sshd can be configured not to allow port forwarding (see AllowTcpForwarding - which alone is not sufficient.. netcat and friends..).

proxy authenticate the user


Again it is usually the case, but one can configure a proxy to serve only specific sessions and one may choose to do so without requiring authentication. Or use authentication, but restrict the server in other ways, and this blows the door wide open. Caution is advised.

xpra proxy could have a white list ..


Allowing the user to specify the session is potentially such a huge gaping hole, that something would have to be done to prevent problems before merging I think. Either using a whitelist, or even disabling the functionality by default (which would force the admin to RTFM).

I did it this is probably because I got an error


pam_auth was indeed broken, fixed for trunk in r6563 and v0.12 / v0.13 in r6564.

I would like to do it after #172 is resolved


Fine with me... there's a lot more to solve there!


Fri, 01 Aug 2014 13:11:21 GMT - Antoine Martin:

Any update on this? Can I close it?


Sun, 17 Aug 2014 14:14:47 GMT - Antoine Martin: status changed; resolution set

Not heard back, closing.


Sat, 23 Jan 2021 04:59:51 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/576