I've been playing with some improvements to how the Linux NFS client
behaves when a server requires a stronger security flavor than
AUTH_UNIX to access its pseudo-fs.
AUTH_UNIX is the default flavor our client uses when no security
flavor preference was specified on the mount command. The client
has to be smart enough to negotiate the security flavor when the
server may require something a little stronger.
Typically servers take a union of security flavors on all their
current real shares and use that set as the security flavors
required for the pseudo-fs. If a server's real shares are exported
with only various flavors of Kerberos, for instance, then the
server's pseudo-fs will not allow AUTH_UNIX access, though the
server might still allow a SETCLIENTID operation with AUTH_UNIX in
this case.
This work is also relevant if we want to consider using an
integrity-protecting security flavor for lease management operations
(such as SETCLIENTID and RENEW) while allowing other flavors for
accessing data or the pseudo-fs.
Version 1 of this series is the result. I've done some testing with
a Linux NFS server configured to require a flavor of Kerberos to
access its pseudo-fs. I also tried some testing with a Solaris NFS
server.
Bryan, I copied you because you originally wrote the find_root_sec
code: any comments, review, or testing is appreciated.
---
Chuck Lever (4):
NFS: Use static list of security flavors during root FH lookup recovery
NFS: Avoid PUTROOTFH when managing leases
NFS: Clean up nfs4_proc_get_rootfh
NFS: Handle missing rpc.gssd when looking up root FH
fs/nfs/nfs4proc.c | 134 ++++++++++++++++++++++++++++++++++++++++-------------
fs/nfs/nfs4xdr.c | 18 +------
2 files changed, 104 insertions(+), 48 deletions(-)
--
Chuck Lever
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
