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.
support socket activation
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.
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.
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)
Debian packaging build fix in r15936
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?)
basic policy for the system proxy server only
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.
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)
New problem seen on centos7: ctypes tries to write to /tmp and fails.
See:
CFFI_TMPDIR doesn't seem to make any difference
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.
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):
xpra info socket:/var/run/xpra/system or xpra info tcp/username:password@HOST/
Conversely, removing the package should undo everything.
Tested on Fedora 26 and centos7.
@smo: mostly a FYI, feel free to close.
crickets - works for me
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.
Fedora 27 broke the selinux policy: #1679
Debian packaging of the ssl cert is a mess: #1721
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1521