Bug 7788 - Snap applications does not work inside ThinLinc session
Summary: Snap applications does not work inside ThinLinc session
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Alexander Zeijlon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-03 09:15 CET by Frida
Modified: 2023-06-07 10:25 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
MUST: * Snap applications should be able to run in Thinlinc sessions, by default or without any additional setup required. * Non-snap applications that depend on the $XAUTHORITY file should still run as before. * If actions are taken that in some way lowers the security level in the X server, this must be thoroughly evaluated and clearly motivated. SHOULD: * The solution should be robust by following best practices in the area instead of just doing a workaround for snaps.

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Frida cendio 2021-11-03 09:15:23 CET 
When running applications installed as snaps inside a ThinLinc session they will not start. They do not have access to the xserver. The applications works just fine locally and if you disable x access control by running:
> xhost +

Tested this on Ubuntu 20.04 with thunderbird 91.2.1 and gimp 2.10.24 installed as snaps. Found this with chromium browser on bug 7476 comment 2, but after some investigations it seems that no snap application work inside ThinLinc session, not only chromium.

The testing was done with:
ThinLinc server 4.13.0post-2328
Thinlinc client 4.13.0post-2242
Server with GNOME desktop 3.36.8
Comment 1 Pierre Ossman cendio 2021-11-03 09:43:42 CET 
$XAUTHORITY handling seems to be a bit broken in snap. I can find these threads about it:

https://forum.snapcraft.io/t/migrate-x11-authentication-cookies-into-snap-environment/116
https://forum.snapcraft.io/t/x11-forwarding-using-ssh/2381

However they have merged a supposed fix:

https://github.com/snapcore/snapd/pull/3177

It should be in snap 2.25 and newer. And Ubuntu 20.04 supposedly has snap 2.51.1. So something with that new fix isn't working.
Comment 2 Pierre Ossman cendio 2022-06-30 10:39:31 CEST 
This has now got worse as it seems like (at least) Firefox is installed as a snap by default on Ubuntu 22.04, and things still don't work:

> cendio@ubuntu2204:~$ firefox
> No protocol specified
> Error: cannot open display: :11
Comment 3 Pierre Ossman cendio 2022-06-30 10:55:59 CEST 
I've found the issue. They only apply their fix if the file is in /tmp:

>	// Only do the migration from /tmp since the real /tmp is not visible for snaps
>	if !strings.HasPrefix(fin.Name(), "/tmp/") {
>		return "", nil
>	}

https://github.com/snapcore/snapd/blob/923eec0c1a07cebd9418c4fe87b33901d66065b2/cmd/snap/cmd_run.go#L621

This is to try to avoid a security issue with this system:

https://github.com/snapcore/snapd/pull/3177#discussion_r111426475
Comment 4 Pierre Ossman cendio 2022-06-30 12:40:36 CEST 
Reported the issue upstream:

https://bugs.launchpad.net/snapd/+bug/1980344
Comment 6 Alexander Zeijlon cendio 2023-06-01 09:21:10 CEST 
After some investigation, we have found that there are two factors that affect being able to start snap applications in a tl-session.
1. The $XAUTHORITY file must be in a *valid* location, which currently seems to be directly in $XDG_RUNTIME_DIR or in some path that has the prefix "/tmp/".
2. The logged-in user must be authorized in the X server.
   - For example, by adding it with the command xhost +si:localuser:<username>.

It seems that only one of the two points above need to be fulfilled for snap applications to work.

Point two is likely the best option since we do not want to either overwrite the default value of $XDG_RUNTIME_DIR, or put the $XAUTHORITY file in /tmp/ since files in this directory are automatically deleted at regular intervals.
Comment 7 Alexander Zeijlon cendio 2023-06-05 11:13:09 CEST 
We tested starting a snap application on a local login. We tested on Gnome with X11 and Gnome with Wayland on both Fedora 38 and Ubuntu 22.04.

Independent of combination of distribution and X11/Wayland, there was no difference in behavior when testing the scenarios described below:
1. The Xauthority file default location, with xhost +SI:localuser:<username> set.
> No issues.
2. The Xauthority file default location, with xhost +SI:localuser:<username> NOT set.
> No issues.
3. The Xauthority file other location, with xhost +SI:localuser:<username> set.
> No issues, no matter where the file was placed.
> We moved the Xauthority file to:
> * /run/ (which is visible in snap),
> * /otherdir/ (which is not visible in snap).
4. The Xauthority file other location, with xhost +SI:localuser:<username> NOT set.
> Snaps start when Xauthority is in:
> * /run/ (which is visible in snap)
> Do NOT start when Xauthority is in:
> * /otherdir/ (which is not visible in snap).
Comment 8 Alexander Zeijlon cendio 2023-06-05 11:22:14 CEST 
The visibility of files in snap could possibly be explained by the mount points that are defined in sc_populate_mount_ns() in snapd/cmd/snap-confine/mount-support.c in the snap source code. https://github.com/snapcore/snapd/blob/20ebeee0abcf15cb9e22badc9ab8426a5bb975d9/cmd/snap-confine/mount-support.c#L943

We can see that /run/ is one of the mount points, which is not the case for the /otherdir/ folder we created ourselves. We have not confirmed that this is actually the case by testing all the defined mount points, but it seems likely that this is the case.
Comment 9 Alexander Zeijlon cendio 2023-06-05 13:26:34 CEST 
Since Gnome Mutter v. 3.33.91, there is a functionality that sets xhost +SI:localuser:<username>, commit [1]. This functionality was removed in v. 42.6, commit [2].

1. https://gitlab.gnome.org/GNOME/mutter/-/commit/eac227a203dba4d45398dfb85ec5b4610b5f3be7
2. https://gitlab.gnome.org/GNOME/mutter/-/commit/b61b0478f7538db27c35dff48f4581a811458116

The removal of the functionality in commit [2] is motivated by the fact that "applications can bypass the X11 permission setting and access the X server through abstract sockets because X11 authentication is not enforced for the current user ID".

However, if this is the case, it would be interesting to know why the distributions themselves still set SI:localuser:<username> through an init-script on login, which is done both by Fedora and Ubuntu when starting Gnome with X11.

This also means that there now is a difference in security level between X11 and Wayland in these distributions. SI:localuser:<username> gets set under X11, but not in Wayland.
This has been reported upstream to Fedora, https://bugzilla.redhat.com/show_bug.cgi?id=2212300.
Comment 10 Alexander Zeijlon cendio 2023-06-07 09:29:49 CEST 
We have been trying to look why the scripts to set SI:localuser:<username> were added, but have not found any commits with any substantial information.

We found the commits that added the scripts that are run for a local login with X11 for both Fedora and Ubuntu, but they have minimal documentation and are quite old (from 2006 and 2012 respectively):
https://src.fedoraproject.org/rpms/xorg-x11-xinit/c/6cf01551afb21a2de9a54fb009d910bb7595fa08
https://git.launchpad.net/ubuntu/+source/xorg/commit/debian/local/Xsession.d/35x11-common_xhost-local?id=cce86cade8c1b22b3955aa15e74fa1cedf948127

The Ubuntu commit refers to a Debian upstream bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586685, we couldn't find any corresponding report in Fedoras bug tracker.

We also investigated if Xorg had any recommendations for when SI:localuser:<username> should be used or not, but we had no luck finding any information on the topic. However, we can still look into why functionality SI:localuser was added, and hopefully there might be some clues in the commit message.
Comment 11 Alexander Zeijlon cendio 2023-06-07 09:36:39 CEST 
The reason why snap applications does not work in ThinLinc is because we place the Xauthority file in a place not accessible to snap (/var/opt/thinlinc/sessions/<user>/). Furthermore, since ThinLinc does not count as a local X11 login, there is no script setting SI:localuser:<username> when logging in. A local X11 login uses the local xinit scripts that are specific to a distribution.

Both these factors means that snap applications won't start since they can't get permission to use the Xserver.

While it would be an easy workaround to add a script that runs xhost +SI:localuser:<username>, this does lower the security level, and it's hard to evalute if this is an acceptable change if we don't know why the distributions considered this lower level as good enough.

We could move our session folders from /var/opt/thinlinc/ to eg. /run/thinlinc/ which would be accessible by snap applications. But this is currently outside the scope of this bug for now, since we are close to release right now and do not have time to fully evaluate possible side effects of such a move.
Note You need to log in before you can comment on or make changes to this bug.