User config ignored if started via proxy

totaam commented 7 years ago

Issue migrated from trac ticket # 1582

component: server | priority: critical

2017-07-17 08:01:02: psycho_zs created the issue

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.

totaam commented 7 years ago

Good catch! (related to #1105)

totaam commented 7 years ago

Seems fixed in r16382.

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

totaam commented 7 years ago

2017-07-17 09:58:13: psycho_zs commented

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

key-shortcut, env, desktop-scaling, dpi

totaam commented 7 years ago

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.

totaam commented 7 years ago

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.

totaam commented 6 years ago

2017-12-14 18:31:57: marcoil commented

User config is still ignored in v2.2-17607, 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.

totaam commented 6 years ago

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.

totaam commented 6 years ago

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.

totaam commented 6 years ago

2017-12-17 04:56:38: antoine commented

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:
add start option (using start here since I don't use exit-with-children, but both work)
```
echo "start=xterm" >.xpra/xpra.conf
```
try with a non-proxied start:
```
xpra start --no-daemon :10
```

and verify that the xterm got started (can also attach to verify visually):

$ grep "started command" /run/user/1000/xpra/:10.log
started command 'xterm' with pid 11028

now try via proxy:
```
xpra stop :10
xpra start --start-via-proxy=yes :10
```
And run those same checks again. Everything checks out.

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

totaam commented 6 years ago

2017-12-21 12:27:38: marcoil commented

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-17715 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.

totaam commented 6 years ago

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)

totaam commented 6 years ago

2017-12-22 11:41:51: marcoil commented

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

Using the proxy system service, the user's ~/.xpra/xpra.conf still isn't followed. Enabling the debug function in source:/trunk/src/xpra/scripts/config.py#L19, it seems like it's the proxy system process the one that reads the configuration files, not the user's xpra server instance.
Starting directly from the client, using SSH, appends the start options, that is, executes both those in /etc/xpra/conf.d and in ~/.xpra/xpra.conf. This may not be related, I'm just mentioning it because you noted that wouldn't be the case.

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

Xpra-org / xpra