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

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.