Okay, I understand what's going on now. I'm not sure what to do about it, though. Hopefully someone else who understands what's going on will be able to help. I suspect that this ticket needs to be reassigned to either nfs-common or to autofs.
maxjos <[email protected]> writes: > From what I could see in the nfs-utils docs though, RPCGSSDOPTS="-n" > means you have to acquire the NFS service ticket as root manually > before the user is able to mount any kerberized exports. This leads me > to believe something is triggered in the login process (as root) > making kerberos able to get the service ticket and insert into my > credentials *IF* my home is NFS mounted. Plausible? Yes. The issue is that there are two separate operations involved in Kerberos-authenticated NFS access so far as I can tell from the gssd man page. (I'm somewhat handicapped here by not using Kerberized NFS; I find AFS a better solution for what I need to do.) First, there's mounting of the file system. Normally, this is done using machine credentials (which presumably means /etc/krb5.keytab). With the -n option, this can instead be done using root's user-space credentials. Second, there's authenticated access to files in the file system once it's mounted. This is presumably done using the user's own regular credentials. The problem, when combined with autofs, is that mounts are done as the root user rather than as the user triggering the autofs mount, but root doesn't have the user's credentials. Hence, autofs mounting doesn't work unless you manually obtain Kerberos credentials as root. That this happens to work when you're auto-mounting the user's home directory is purely an accident of implementation in pam-krb5. It relies on unsupported and undocumented behavior of pam-krb5 and could well break again in future versions. Due to some implementation difficulties with how OpenSSH does authentication, pam-krb5 saves a temporary ticket cache to the file system during the auth stack and then moves that ticket cache to the user's proper final ticket cache during the session stack (or setcred call). That temporary ticket cache is only intended to be used internally by pam-krb5; that it's stored in the file system at all is only because OpenSSH doesn't pass PAM data around in a way that would let it be kept only in memory. Because it's only used internally, pam-krb5 doesn't bother chowning it, which means it's owned by root. rpc.gssd happens to find that ticket cache when autofs fires during the login process and, since it's owned by root, happily uses it to do the mount. This is actually something of a security weirdness in how rpc.gssd works -- there's a race condition here in its scan of /tmp for root-owned tickets and possible logins that could lead it to mounting a user's home directory using some other user's credentials. This is an inherent security flaw in how rpc.gssd works, which is probably not fixable as long as it scans /tmp for ticket caches and uses whatever it happens to find. If autofs happens later, after the PAM authentication has successfully completed, this temporary ticket cache of course no longer exists and therefore the mount cannot be done. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- Kerberos, NFS4 and autofs issue https://bugs.launchpad.net/bugs/368153 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
