On Mon, May 06, 2013 at 09:27:54AM -0400, Weston Andros Adamson wrote:
> Older clients match the 'sec=' mount option flavor against the server's
> flavor list (if available) and return EPERM if the specified flavor is not
> found. Recent changes would skip this step and allow the vfs mount even
> though no operations will succeed.
>
> Signed-off-by: Weston Andros Adamson <dros@xxxxxxxxxx>
> ---
>
> Hey Chuck,
>
> This fixes a regression that was introduced with the recent nfs_select_flavor
> changes - I'm pretty sure we want to match the specified flavor instead of just
> using it.
>
> Example of the regression:
>
> the server's /etc/exports:
>
> /export/krb5 *(sec=krb5,sec=none,rw,no_root_squash)
>
> old client behavior:
>
> $ uname -a
> Linux one.apikia.fake 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
> mount.nfs: timeout set for Sun May 5 17:32:04 2013
> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
> mount.nfs: prog 100003, trying vers=3, prot=6
> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
> mount.nfs: prog 100005, trying vers=3, prot=17
> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
> mount.nfs: mount(2): Permission denied
> mount.nfs: access denied by server while mounting zero:/export/krb5
>
> recently changed behavior:
>
> $ uname -a
> Linux one.apikia.fake 3.9.0-testing+ #2 SMP Fri May 3 20:29:32 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
> $ sudo mount -v -o sec=sys,vers=3 zero:/export/krb5 /mnt
> mount.nfs: timeout set for Sun May 5 17:37:17 2013
> mount.nfs: trying text-based options 'sec=sys,vers=3,addr=192.168.100.10'
> mount.nfs: prog 100003, trying vers=3, prot=6
> mount.nfs: trying 192.168.100.10 prog 100003 vers 3 prot TCP port 2049
> mount.nfs: prog 100005, trying vers=3, prot=17
> mount.nfs: trying 192.168.100.10 prog 100005 vers 3 prot UDP port 20048
> $ ls /mnt
> ls: cannot open directory /mnt: Permission denied
> $ sudo ls /mnt
> ls: cannot open directory /mnt: Permission denied
> $ sudo df /mnt
> df: ‘/mnt’: Permission denied
> df: no file systems processed
> $ sudo umount /mnt
> $
>
> I also made an attempt to support "AUTH_NULL means the server will ignore the
> cred, so just use the specified flavor" behavior from much older kernels, but
> I'm not sure if we want this logic.
>
> I'd actually prefer getting rid of this AUTH_NULL logic, it's just that some
> older clients (RHEL 5, etc) would succeed in mounting when sec=sys specified,
> server list = [AUTH_NULL] (the client ends up sending AUTH_UNIX creds that are
> ignored by the server), while newer kernels do not. The workaround in newer
> kernels is to specify sec=none.
Nit: the above examples would actually be really useful, for example, to
a distribution maintainer trying to figure out whether this patch would
solve a given user problem.
Could you include them in the changelog?
--b.
>
> Thoughts?
>
> -dros
>
> fs/nfs/super.c | 39 ++++++++++++++++++++++++++++++++-------
> 1 file changed, 32 insertions(+), 7 deletions(-)
>
> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
> index eb494f6..6476b5d 100644
> --- a/fs/nfs/super.c
> +++ b/fs/nfs/super.c
> @@ -1611,14 +1611,12 @@ out_security_failure:
> * Select a security flavor for this mount. The selected flavor
> * is planted in args->auth_flavors[0].
> */
> -static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
> +static int nfs_select_flavor(struct nfs_parsed_mount_data *args,
> struct nfs_mount_request *request)
> {
> unsigned int i, count = *(request->auth_flav_len);
> rpc_authflavor_t flavor;
> -
> - if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR)
> - goto out;
> + bool auth_null_seen = false;
>
> /*
> * The NFSv2 MNT operation does not return a flavor list.
> @@ -1634,6 +1632,26 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
> goto out_default;
>
> /*
> + * If the sec= mount option is used, the flavor must be in the list
> + * returned by the server.
> + *
> + * One exception is when the server's flavor list includes AUTH_NULL:
> + * Some servers implement AUTH_NULL by completely ignoring the rpc
> + * cred, so the client can use any flavor.
> + */
> + if (args->auth_flavors[0] != RPC_AUTH_MAXFLAVOR) {
> + for (i = 0; i < count; i++) {
> + if (args->auth_flavors[0] == request->auth_flavs[i])
> + goto out;
> + if (request->auth_flavs[i] == RPC_AUTH_NULL)
> + auth_null_seen = true;
> + }
> + if (auth_null_seen)
> + goto out;
> + goto out_nomatch;
> + }
> +
> + /*
> * RFC 2623, section 2.7 suggests we SHOULD prefer the
> * flavor listed first. However, some servers list
> * AUTH_NULL first. Avoid ever choosing AUTH_NULL.
> @@ -1654,11 +1672,19 @@ static void nfs_select_flavor(struct nfs_parsed_mount_data *args,
> }
>
> out_default:
> - flavor = RPC_AUTH_UNIX;
> + /* use default if flavor not already set */
> + flavor = (args->auth_flavors[0] == RPC_AUTH_MAXFLAVOR) ?
> + RPC_AUTH_UNIX : args->auth_flavors[0];
> out_set:
> args->auth_flavors[0] = flavor;
> out:
> dfprintk(MOUNT, "NFS: using auth flavor %d\n", args->auth_flavors[0]);
> + return 0;
> +
> +out_nomatch:
> + dfprintk(MOUNT, "NFS: auth flavor %d not supported by server\n",
> + args->auth_flavors[0]);
> + return -EPERM;
> }
>
> /*
> @@ -1721,8 +1747,7 @@ static int nfs_request_mount(struct nfs_parsed_mount_data *args,
> return status;
> }
>
> - nfs_select_flavor(args, &request);
> - return 0;
> + return nfs_select_flavor(args, &request);
> }
>
> struct dentry *nfs_try_mount(int flags, const char *dev_name,
> --
> 1.7.12.4 (Apple Git-37)
>
> --
> 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
--
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
