Comment 18 for bug 1784774

It may also be worth noting that Kerberos/GSSAPI authentication for NFS works a bit differently from Kerberos/GSSAPI authentication for applications, because NFS happens in the kernel, and therefore the kernel needs to get access to the Kerberos tickets (credentials). The kernel's NFS client does so via a helper process called rpc.gssd, which is usually started at boot time as a daemon by systemd, then listens on /run/rpc_pipefs for kernel requests (upcalls) to authenticate an NFS RPCSEC_GSS session via Kerberos, and then does execure the Kerberos protocol in user space, and passes the resulting session key back to the RPCSEC_GSS code in the kernel, which then uses it to cryptographically protect the NFS RPC requests that go over the network. While doing this, the rpc.gssd process takes on the effective UID of the user application that made the NFS file/IO request, and as such reads the Kerberos ticket, traditionally from the user's credential cache at /tmp/krb5cc_$UID or (depending on the value of $KRB5CCNAME) from some other credential cache, e.g. the kernel keyring.

So the question is: if rpc.gssd does take over the control flow, UID, and environment variables of an NFS I/O request made by a snap application, does it effectively run, from AppArmor's point of view, as the snap application that tried to access a file via Kerberized NFS? Does then the AppArmor profile of the snap application therefore also apply to rpc.gssd and therefore have to enable it to read the Kerberos ticket, such that rpc.gssd can inherit that right as well?

If you run AppArmor in complaint mode rather than enforce mode, does it report in the log that it would have prevented rpc.gssd from doing its thing (reading the ticket, using the network, etc.)
?

KRB5CCNAME syntax: https://web.mit.edu/kerberos/krb5-1.17/doc/basic/ccache_def.html