NFS access not permitted for snap's on LDAP autofs system

[Markus Kuhn]

Snaps are normally confined via AppArmor to not have network access. Unfortunately, when AppArmor blocks network access, it also blocks all NFS access by the confined process via the normal kernel filesystem API. That renders snaps pretty much unusable on centrally-managed Linux workstation pools (e.g. very widely used in university departments and some larger enterprise environments) where home directories (or other files that the user wants to work with using the snap) sit on a file server and are automounted via root-squashed NFS. As a workaround, snapd tries to detect at start-up time whether a system has nfs or nfs4 or (since https://github.com/snapcore/snapd/pull/8936 ) autofs mounted file systems, and then disables blocking network access to snaps, such that they can access NFS files.

However, if autofs is configured via LDAP, then the automounts will be established relatively late in the boot process (after the network and autofs are up and the LDAP server has responded), usually long after snapd has already checked if there are any autofs mounts.

As a result, snaps still fail, e.g.

$ pdftk
2021/03/01 14:50:27.440720 cmd_run.go:573: WARNING: XAUTHORITY environment value is not a clean path: "/run/lightdm/mgk25/xauthority"
cannot create user data directory: /home/mgk25/snap/pdftk/9: Stale file handle

A workaround is to manually restart snapd with

# systemctl restart snapd

such that it can see the autofs mount in place for /home, and then not confine network access as a workaround.

Is there an easy way to manually completely disable network confinement for snaps? Snaps's current attempts to auto-detect that this is necessary are not working well everywhere, and system administrators therefore will need the ability to override auto-detect mechanisms for NFS use, because that simply can't be done reliably automatically during boot.

On our systems, for example, LDAP-configured autofs can be recognized by having in /etc/nsswitch.conf the line

  automount: ldap

but I would not recommend that snapd starts trying to parse such glibc config files, as they may change and have non-trivial syntax.

I've also tried to solve the problem via "snap install --classic pdftk", but that just resulted in a message reporting that option "--classic" is being ignored.

[Markus Kuhn (markus-kuhn)]

Root problem: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1784499

[Zygmunt Krynicki (zyga)]

There's no way to disable network confinement. While snapd is not looking at nsswitch.conf for this particular purpose, perhaps it would be acceptable to extend it. I can provide a patch for review by the snapd maintainers.

[Manfred Thole (tanfred)]

Using LDAP is not necessary to face this issue. The probability that snapd starts before automounts are established is just higher with LDAP. It looks like the start order needs to be enforced.

If

After=autofs.service

is added to [Unit] of /lib/systemd/system/snapd.service users with automounted homes can start snaps. Of course an alternative would be to use Before=snapd.service in /lib/systemd/system/autofs.service. Whatever is more appropriate.

However, this bug is still present in 21.10 where a very prominent application is now by default a snap: firefox
And this issue needs to be sorted out before 22.04 LTS.

[Alberto Mardegan (mardy)]

We should extend snapd to consider /etc/auto.master.d/ and add the network rules for snap-confine even if currently no nfs FS is mounted, if autofs is used.

[Juan Antonio Martinez (jantonio-6)]

Notice that this problem is not only related to autofs: I suffer same problem by using "pam_mount.so" PAM module when "pam_mount.conf.xml" is configured to mount either CIFS or NFS shared /home/<user> directory