[winswitch] Various mountpoints (both /dev/sd* and NFSv4) readonly after xpra session created

[Antoine Martin]

Hi,

The problem you describe is very likely to be caused by the
"ProtectSystem" systemd exec option, see:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html

We set it to "strict", which may be too strict.. Your options are:
* change from "strict" to "full", or even "off".
* add paths to "ReadWritePaths" as needed
* start xpra with "start-via-proxy=no" (you will lose session management
integration)

Which option is best for you depends on your requirements in terms of
ease of maintenance, security, etc..
We could change the default from "strict" to "full" if this causes too
many problems.

Cheers
Antoine

PS: the file you are looking for is:
/usr/lib/systemd/system/xpra.service
But you should not edit that file directly, instead use:
systemctl edit xpra.service
Or create the file by hand in:
/etc/systemd/system/xpra.service


On 15/08/17 03:32, WireRydr via shifter-users wrote:
> Hello there;
> 
> First-off, let me preface this by admitting I cannot tell if this a
> strictly-xpra issue, strictly-Fedora 26 issue, silliness in Systemd,
> operator-stupidity on my part, or some combination of the above.  I've gone
> back through 2-1/2 years of the mailing-list archives, and googled every
> pertinent term I could think of, but I haven't had much luck.
> 
> Environment Details
> -------------------
>   Host OS:      Fedora 26 (x86_84)
>   xpra Server:	2.2-0.20170811r16688.fc26 (from WinSwitch beta repo)
>   Client OS:	Windows 10 (yuck!)
>   xpra client:	Xpra 2.2 (64-bit) revision 16657 (2017-08-08)
> 
> I'm using the repo-supplied 'xpra.service' unit file to start xpra on the
> host.  This works, properly bringing up an xpra proxy, and I can
> successfully create a session through it from my client (with an existing
> non-root account).
> 
> However, I have found that many of my filesystem mounts are (both /dev/sd*
> and NFSv4 mounts) are read-only.  This happens both in terminals (tested in
> xterm and gnome-terminal), and with other apps (e.g. Calibre, brasero,
> devedeng, etc.).  If I directly ssh into the host from my client PC with
> that same non-root account then the filesystems appear properly as
> read-write.  Same is true if I ssh from xterm (inside the xpra session) to
> user at localhost - mounts are now read-write.
> 
> Also within that xterm, I can do things like "sudo mount -o remount,rw
> <mountpoint>" successfully.  However this won't work for non-terminal apps
> without writing wrappers, etc.  It also doesn't address whatever my
> root-cause is.
> 
> I suspect this has something to do with how the user-session environment is
> being set up, but I'm enough of a Systemd noob that I have no idea how to
> troubleshoot the problem.
> 
> 
> 
> For what it's worth, here's 'ps -ef' output showing both the xpra proxy
> process started by the Systemd unit file, and the processes that are spawned
> when I start up the actual xpra session:
> 
> root      8105     1  0 16:05 ?        00:00:00 /usr/bin/python2
> /usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=allow
> --ssl-cert=/etc/letsencrypt/live/example.com/cert.pem --bind=none
> --auth=allow --socket-dirs=/run/xpra --socket-permissions=666
> --log-dir=/var/log --pidfile=/run/xpra.pid --debug=
> testuser  8156     1  2 16:05 ?        00:00:15 /usr/bin/python2
> /usr/bin/xpra start --csc-modules=all --attach=no --start-via-proxy=no
> --packet-encoders=rencode, bencode, yaml --video-decoders=all
> --encodings=all --compressors=lz4, lzo, zlib --video-encoders=all
> --env=XPRA_PROXY_START_UUID=f42ee27577b24606a04bf6dc3feeb251 --daemon=yes
> --systemd-run=no --uid=1000 --gid=1000 --displayfd=17
> testuser  8157  8156  0 16:05 ?        00:00:05
> /usr/libexec/Xorg-for-Xpra-S8152 -noreset -novtswitch -nolisten tcp
> +extension GLX +extension RANDR +extension RENDER -auth /root/.Xauthority
> -logfile /run/user/1000/xpra/Xorg.S8152.log -configdir
> /run/user/1000/xpra/xorg.conf.d/8156 -config /etc/xpra/xorg.conf -depth 24
> -displayfd 8
> testuser  8255  8105  1 16:06 ?        00:00:10 /usr/bin/python2
> /usr/bin/xpra proxy :14500 --daemon=no --tcp-auth=allow
> --ssl-cert=/etc/letsencrypt/live/example.com/cert.pem --bind=none
> --auth=allow --socket-dirs=/run/xpra --socket-permissions=666
> --log-dir=/var/log --pidfile=/run/xpra.pid --debug=
> testuser  8317  8156  3 16:06 ?        00:00:22 /usr/bin/python2
> /usr/bin/xpra _sound_record - - pulsesrc device=Xpra-Speaker.monitor
> opus+ogg  1.0
> testuser  9872  8441  0 16:17 pts/4    00:00:00 grep --color=auto xpra
> 
> I cannot find anything seemingly related to this in the xpra logs, but I can
> provide if requested.
> 
> Any suggestions, or tips on how to better troubleshoot this, would be
> very-greatly appreciated.
> 
> Thank you
> 
> _______________________________________________
> shifter-users mailing list
> shifter-users at lists.devloop.org.uk
> http://lists.devloop.org.uk/mailman/listinfo/shifter-users
>