Xpra: Ticket #1521: socket activation for system proxy server

May help with #1105.

Looks simple enough.

We can probably do this no matter what, if the server is not socket-activated this will do nothing.



Sun, 21 May 2017 12:31:00 GMT - Antoine Martin: attachment set

support socket activation


Sun, 21 May 2017 12:37:59 GMT - Antoine Martin: status changed

The patch above almost works, but I had to disable selinux to avoid this avc denial:

systemd[1]: xpra.socket: Failed to listen on sockets: Permission denied
systemd[1]: Failed to listen on Xpra Socket.
systemd[1]: xpra.socket: Unit entered failed state.
audit[1]: AVC avc:  denied  { create } for  pid=1 comm="systemd" \
    scontext=system_u:system_r:init_t:s0 \
    tcontext=system_u:system_r:unconfined_service_t:s0 \
    tclass=tcp_socket permissive=0

Then you can test with:

#install latest xpra
systemctl daemon-reload
systemctl stop xpra.service
systemctl restart xpra.socket
systemctl status xpra.socket
xpra info socket:/var/run/xpra/system
#or
#xpra info tcp:127.0.0.1

And the "system" instance is started.


Sun, 21 May 2017 16:00:22 GMT - Antoine Martin:

Merged in r15895 with one caveat: the TCP socket is not socket activated yet because of the selinux AVC - which looks like this ticket: SELinux does not allow systemd to create a TCP/UDP socket.

The proxy server now uses the "peercred" auth module (see #1524). The unix domain socket location has been changed to /var/run/xpra/system. This new socket location is not seen by default by subcommands like "xpra list". (r15896 prevents us from creating another one as /var/run/xpra/${hostname}-14500 - which isn't useful anyway)

Keeping this ticket open until the AVC problem is resolved, so we can add the TCP socket to the systemd socket activation.


Sun, 21 May 2017 19:08:54 GMT - Antoine Martin: priority changed

Dammit, even the unix domain socket is broken with selinux enabled. Raising.

Maybe we need a policy? Hopefully just a simple label for the service file? (not a full policy #1283)


Wed, 24 May 2017 05:10:45 GMT - Antoine Martin:

Debian packaging build fix in r15936


Fri, 02 Jun 2017 16:41:21 GMT - Antoine Martin: priority changed

r15995 uses the lax selinux policy so we no longer block #1105, but this will need to be done properly before the release. We want to change from:

allow init_t unconfined_service_t:unix_stream_socket { create setopt bind listen };
allow init_t unconfined_service_t:tcp_socket { create setopt bind listen };

To something much more strict, labelling the unix domain socket and adding another type for the tcp socket. (ie: xpra_socket_t?)


Sat, 03 Jun 2017 19:55:43 GMT - Antoine Martin: attachment set

basic policy for the system proxy server only


Sun, 04 Jun 2017 19:54:36 GMT - Antoine Martin: owner, status changed

SELinux policy added in r16014, RPM packaging in r16015.

It is incomplete, I don't quite understand why some files are labelled correctly:

$ ls -lZ /lib/systemd/system/xpra* /usr/bin/xpra* /var/run/xpra.pid
-rw-r--r--. 1 root root system_u:object_r:xpra_unit_file_t:s0 760 Jun  4 19:32 /lib/systemd/system/xpra.service
-rw-r--r--. 1 root root system_u:object_r:xpra_unit_file_t:s0 304 Jun  4 19:32 /lib/systemd/system/xpra.socket
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      384 Jun  4 19:31 /usr/bin/xpra
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      208 Jun  4 19:31 /usr/bin/xpra_browser
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      226 Jun  4 19:31 /usr/bin/xpra_launcher
-rw-------. 1 root root system_u:object_r:xpra_pid_t:s0         5 Jun  4 21:31 /var/run/xpra.pid

But others aren't:

$ ls -lZ /var/run/xpra/system
srw-rw-rw-. 1 root xpra system_u:object_r:var_run_t:s0 0 Jun  4 21:31 /var/run/xpra/system

So the policy ends up being less strict than it could be. But it is still better than no policy and it does not lower the restrictions on any other domains, unlike the naive audit2allow solution. We can follow up in #1283.


@afarr: mostly a FYI, see comment:1 for testing. Both sockets should be listening as soon as the package is installed: /run/xpra/system (unix domain socket) and 0.0.0.0:14500. Trying to connect to either of them will cause the xpra.service to start. This can be seen using journalctl -f or systemctl status xpra.service.


Tue, 13 Jun 2017 12:34:34 GMT - Antoine Martin:

r16058 fixes the following warnings on centos7:

[/usr/lib/systemd/system/xpra.service:16] Failed to parse protect system value, ignoring: strict
[/usr/lib/systemd/system/xpra.service:17] Unknown lvalue 'ReadWritePaths' in section 'Service'
[/usr/lib/systemd/system/xpra.service:19] Unknown lvalue 'ProtectKernelTunables' in section 'Service'
[/usr/lib/systemd/system/xpra.service:20] Unknown lvalue 'ProtectControlGroups' in section 'Service'

(older systemd versions just don't have those options)


Tue, 13 Jun 2017 14:41:11 GMT - Antoine Martin:

New problem seen on centos7: ctypes tries to write to /tmp and fails. See:


Tue, 13 Jun 2017 19:46:51 GMT - Antoine Martin:

Updated policy as of r16066 allows us to call the pam authentication plugin used by the system proxy server. Was not easy to figure out as some avc denials were hidden, uncovered them with semodule -DB. Tested repeatedly with:

semanage port -d -p tcp 14500
semodule -r xpra_socketactivation
make clean && make
semodule -i xpra_socketactivation.pp
semanage port -a -t xpra_port_t -p tcp 14500
systemctl stop xpra.service
systemctl restart xpra.socket
systemctl status xpra.socket

I think there may still be a problem with package upgrades vs installs, so taking the ticket back for further package installation testing.


Wed, 14 Jun 2017 21:01:24 GMT - Antoine Martin: owner changed

Lots of tricksy RPM packaging fixes:

Reference link: Fedora Packaging Guidelines for RPM Scriptlets


With these changes, the RPM transaction should not be emitting any warnings and the following pieces should always be in a consistent state (after an install or upgrade):

Conversely, removing the package should undo everything.

Tested on Fedora 26 and centos7.

@smo: mostly a FYI, feel free to close.


Thu, 20 Jul 2017 07:14:44 GMT - Antoine Martin: status changed; resolution set

crickets - works for me


Sun, 10 Sep 2017 08:55:05 GMT - Antoine Martin:

Re-tested as I investigated a proxy server bug on Ubuntu 16.04 and found that all Debian / Ubuntu distros were enabling and starting the service instead of relying on socket activation. r16813 fixes that. (will backport) Unfortunately, that doesn't make any difference to Ubuntu 16.04, which still starts the service and somehow also gets the sockets messed up: the service is unreachable as both the 0.0.0.0:14500 and /run/xpra/system sockets timeout. So r16814 + r16815 uses a custom service file without socket activation, just for Ubuntu 16.04. PITA.

For SSL issues, see #1636.


Thu, 09 Nov 2017 07:09:00 GMT - Antoine Martin:

Fedora 27 broke the selinux policy: #1679


Wed, 13 Dec 2017 07:13:34 GMT - Antoine Martin:

Debian packaging of the ssl cert is a mess: #1721


Sat, 23 Jan 2021 05:26:35 GMT - migration script:

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