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 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1784774 Title: snapd is not autofs aware and fails with nfs home dir Status in snapd: Fix Released Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: Fix Released Bug description: This is similar to bugs 1662552 and 1782873. In 1782873, jdstrand asked me to open a new bug for this specific issue. In 1662552, snapd fails for nfs mounted home directories as network permissions are not enabled. A work around was implemented that works if the mount is done via a /home mount at boot. However this does not work if people mount home directories via autofs. This is probably the fundamental problem for 1782873 although there may be other issues. [ Why use autofs? If some but not all of users want to use nfs homes. In particular, I have a local user on all my accounts that does not require the nfs server to be up or the kerberos server to be up, or kerberos working on the client machines, etc. It is very useful when something goes wrong. It means I mount /home/user rather than /home (for several users). ] To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1784774/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
