Comment 5 for bug 368153

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 address hidden> 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 address hidden>) <http://www.eyrie.org/~eagle/>