xpra icon
Bug tracker and wiki

Opened 11 months ago

Last modified 6 months ago

#1582 new defect

User config ignored if started via proxy

Reported by: psycho_zs Owned by: Marc Ordinas i Llopis
Priority: critical Milestone: 2.3
Component: server Version: trunk
Keywords: Cc: mail@…

Description

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.

Change History (13)

comment:1 Changed 11 months ago by Antoine Martin

Status: newassigned

Good catch!
(related to #1105)

comment:2 Changed 11 months ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs
Status: assignednew

Seems fixed in r16382.

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

comment:3 Changed 11 months ago by 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

comment:4 Changed 11 months ago by 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.

comment:5 Changed 11 months ago by Antoine Martin

Resolution: worksforme
Status: newclosed

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.

comment:6 Changed 6 months ago by Marc Ordinas i Llopis

Cc: mail@… added

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.

comment:7 Changed 6 months ago by Antoine Martin

Resolution: worksforme
Status: closedreopened

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.

comment:8 Changed 6 months ago by Antoine Martin

Milestone: 2.12.3
Owner: changed from psycho_zs to Antoine Martin
Status: reopenednew

comment:9 Changed 6 months ago by Antoine Martin

Priority: majorcritical

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.

comment:10 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to Marc Ordinas i Llopis

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 wiki/ReportingBugs so that I can have enough details to reproduce the problem.
Otherwise this ticket will be closed as "fixed".

comment:11 Changed 6 months ago by 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.

comment:12 Changed 6 months ago by 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)

comment:13 Changed 6 months ago by Marc Ordinas i Llopis

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 start = xterm in ~/.xpra/xpra.conf. Using the proxy server, only xeyes appears. Using SSH, both xeyes and xterm are started.

Note: See TracTickets for help on using tickets.