Xpra: Ticket #1582: User config ignored if started via proxy

using 2.1-20170715r16357-1, when server is started via system service, user config is ignored. When starting with --start-via-proxy=no, user config is successfully applied.



Mon, 17 Jul 2017 07:03:46 GMT - Antoine Martin: status changed

Good catch! (related to #1105)


Mon, 17 Jul 2017 08:48:07 GMT - Antoine Martin: owner, status changed

Seems fixed in r16382.

(unfortunately, we have to whitelist the options that do get forwarded so it is possible I've missed one)


Mon, 17 Jul 2017 08:58:13 GMT - psycho_zs:

Haven't tested yet, but there are options I didn't find in PROXY_START_OVERRIDABLE_OPTIONS:

key-shortcut, env, desktop-scaling, dpi


Mon, 17 Jul 2017 09:13:23 GMT - Antoine Martin:

Options like key-shortcut, desktop-scaling are only used by the client so they don't need to be forwarded. dpi: the client will forward it to the server on connection, which is a little bit different admittedly, so r16384 fixes that. env and start-env added in r16383.


Tue, 25 Jul 2017 16:57:15 GMT - Antoine Martin: status changed; resolution set

Important fix as part of r16502 (for #1105 mostly): we don't want to honour env when running as root. A user could potentially use this to subvert the system wide proxy service.

Closing, feel free to re-open if I've missed something.


Thu, 14 Dec 2017 18:31:56 GMT - Marc Ordinas i Llopis: cc set

User config is still ignored in v2.2-r17607, but I'm not sure if it is the intended behavior.

To test, just add a ~/.xpra/xpra.conf file for an user with "start-child = xterm" and start a server through a proxy system service, the user configuration file is ignored.

If this is the intended behavior, maybe there should be a proxy setting to allow users to use their own config files.


Thu, 14 Dec 2017 18:37:21 GMT - Antoine Martin: status changed; resolution deleted

Ah. The config loading runs as root, very early on, before parsing the command line, and before changing uid... Not sure if that can be fixed.


Thu, 14 Dec 2017 18:37:32 GMT - Antoine Martin: owner, status, milestone changed


Thu, 14 Dec 2017 19:09:39 GMT - Antoine Martin: priority changed

DOH. I've just remembered how this is supposed to work: the xpra start --start-child=XX command does the command line parsing and forwards all command line options to the system proxy server, so there is no need to fiddle with the early command line parsing.


Sun, 17 Dec 2017 04:56:37 GMT - Antoine Martin: owner changed

To test, just add a ~/.xpra/xpra.conf file for an user with "start-child = xterm" and start a server through a proxy system service, the user configuration file is ignored.

I cannot reproduce the problem:

And run those same checks again. Everything checks out.

@Marc Ordinas i Llopis: if you still have problems, please follow wiki/ReportingBugs so that I can have enough details to reproduce the problem. Otherwise this ticket will be closed as "fixed".


Thu, 21 Dec 2017 12:27:38 GMT - Marc Ordinas i Llopis:

I'm using the same version on the client (Linux Mint 18.3) and the server (Ubuntu 17.10), the deb package 2.2.1-r17715 from the winswitch repository.

I start the system proxy server using systemctl start xpra, this launches an xpra proxy instance with this command line:

/usr/bin/python /usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=sys --ssl-cert=/etc/xpra/ssl-cert.pem --ssl=on --bind=none --auth=peercred --socket-dirs=/run/xpra --socket-permissions=666 --log-dir=/var/log --pidfile=/run/xpra.pid --debug=

The contents of ~\.xpra/xpra.conf are simply

start=xterm

Then, from the client, I start a new server:

client$ xpra start ssl://user:passwd@server.tld:14500

This gets to the proxy, who starts a new xpra process as the user with this command line:

/usr/bin/python /usr/bin/xpra start --video-decoders=all --packet-encoders=rencode, bencode, yaml --video-encoders=all --encodings=all --compressors=lz4, lzo, zlib --csc-modules=all --attach=no --start-via-proxy=no --env=XPRA_PROXY_START_UUID=6aa0e8f44f674598908cf47f3c7b747c --daemon=yes --systemd-run=no --uid=1000 --gid=1000 --displayfd=16

This also starts the X and pulseaudio servers, but not xterm as set in ~/.xpra/xpra.conf.

The problem may be related to the deb packaging and not to the code. Or maybe this is the intended behavior when using a system proxy server, but I'm not sure from the documentation.

I can provide logs of all the above if needed.


Thu, 21 Dec 2017 16:50:33 GMT - Antoine Martin:

Thanks, I must have done something different when I tested, as I managed to reproduce the problem immediately with your steps. The fixes are in r17718 + r17719.

Unfortunately, those fixes are the intrusive kind that normally makes me nervous about backporting, so I am tempted to call this a "known issue" in 2.2 and only carry the fix forward for the next release. That way it will get more testing before being released into the wild.

Note: at present, if the client specifies start=xterm, it will override any start=whatever that the server might have had. One could reasonably argue that we should append to the list. Problem with this approach is that it then becomes impossible to override the server's start option - which could be seen as a feature too.

@Marc Ordinas i Llopis: does that work for you? (new beta builds pushed)


Fri, 22 Dec 2017 11:41:51 GMT - Marc Ordinas i Llopis:

Testing with version 2.3-r17719, from the beta repository, I'm getting very different results:

I'm testing by having an start = xeyes in /etc/xpra/conf.d and start = xterm in ~/.xpra/xpra.conf. Using the proxy server, only xeyes appears. Using SSH, both xeyes and xterm are started.


Sat, 23 Jan 2021 05:28:19 GMT - migration script:

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