diff options
author | Chuck Lever <chuck.lever@oracle.com> | 2013-03-16 15:56:20 -0400 |
---|---|---|
committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2013-03-29 15:45:22 -0400 |
commit | 4edaa308888b4bd629fa025cc6d5b2bf1a2a51db (patch) | |
tree | 0b98de1389a22bea9f12f698f848b7cb63424f1c /fs/nfs/dns_resolve.c | |
parent | c4eafe1135809c2b35b873a395af8f3a86a3ee98 (diff) | |
download | op-kernel-dev-4edaa308888b4bd629fa025cc6d5b2bf1a2a51db.zip op-kernel-dev-4edaa308888b4bd629fa025cc6d5b2bf1a2a51db.tar.gz |
NFS: Use "krb5i" to establish NFSv4 state whenever possible
Currently our client uses AUTH_UNIX for state management on Kerberos
NFS mounts in some cases. For example, if the first mount of a
server specifies "sec=sys," the SETCLIENTID operation is performed
with AUTH_UNIX. Subsequent mounts using stronger security flavors
can not change the flavor used for lease establishment. This might
be less security than an administrator was expecting.
Dave Noveck's migration issues draft recommends the use of an
integrity-protecting security flavor for the SETCLIENTID operation.
Let's ignore the mount's sec= setting and use krb5i as the default
security flavor for SETCLIENTID.
If our client can't establish a GSS context (eg. because it doesn't
have a keytab or the server doesn't support Kerberos) we fall back
to using AUTH_NULL. For an operation that requires a
machine credential (which never represents a particular user)
AUTH_NULL is as secure as AUTH_UNIX.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'fs/nfs/dns_resolve.c')
0 files changed, 0 insertions, 0 deletions