Changes:
v4:
- fake up server list in nfs_mount rather than in nfs_try_mount_request.
This simplifies the auth selection code by allowing it to always
assume that it has a non-empty authlist from the mount request.
v3:
- fix some signed vs. unsigned type comparisons
- change how an empty server_authlist is handled. Instead of picking an
authflavor to try at that point, just munge the list to contain only
RPC_AUTH_NULL. The rest of the logic can take over at that point.
I got a report of a regression in recent kernels. Windows 2012 servers
support v3 and v4.1. They also return a list of authflavors that starts
with AUTH_GSS flavors and ends with AUTH_SYS.
Since commit 4580a92 (NFS: Use server-recommended security flavor by
default (NFSv3)) mounting this server with nfsv3 fails unless you
specify sec=sys. I can replicate the problem with a Linux NFS server
by exporing a filesystem with "sec=krb5:sys".
This patchset overhauls the NFSv3 auth code to try each authflavor in
the list provided by the server in the order that it specified them.
With this, I'm again able to mount the server without needing any
special mount options.
Thanks to Chuck Lever for suggestions thus far...
Jeff Layton (4):
nfs: refactor "need_mount" code out of nfs_try_mount
nfs: move server_authlist into nfs_try_mount_request
nfs: have nfs_mount fake up a auth_flavs list when the server didn't
provide it
nfs: have NFSv3 try server-specified auth flavors in turn
fs/nfs/mount_clnt.c | 18 +++++-
fs/nfs/super.c | 175 ++++++++++++++++++++++++++++------------------------
2 files changed, 110 insertions(+), 83 deletions(-)
--
1.8.1.4
--
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
