From: "Matt W. Benjamin" <matt@linuxbox.com>
To: Weston Andros Adamson <dros@netapp.com>
Cc: linux-nfs@vger.kernel.org, Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: Re: [PATCH] NFSv4: use mach cred for SECINFO_NO_NAME w/ integrity
Date: Wed, 4 Sep 2013 12:29:08 -0400 (EDT) [thread overview]
Message-ID: <1816381628.87.1378312148730.JavaMail.root@thunderbeast.private.linuxbox.com> (raw)
In-Reply-To: <983545972.85.1378311975965.JavaMail.root@thunderbeast.private.linuxbox.com>
Hi
It honestly feels quite odd to me for sec=sys to actually connote krb5i.
Matt
----- "Weston Andros Adamson" <dros@netapp.com> wrote:
> Commit 97431204ea005ec8070ac94bc3251e836daa7ca7 introduced a
> regression
> that causes SECINFO_NO_NAME to fail without sending an RPC if:
>
> 1) the nfs_client's rpc_client is using krb5i/p (now tried by
> default)
> 2) the current user doesn't have valid kerberos credentials
>
> This situation is quite common - as of now a sec=sys mount would use
> krb5i for the nfs_client's rpc_client and a user would hardly be
> faulted
> for not having run kinit.
>
> The solution is to use the machine cred when trying to use an
> integrity
> protected auth flavor for SECINFO_NO_NAME.
>
> Older servers may not support using the machine cred or an integrity
> protected auth flavor for SECINFO_NO_NAME in every circumstance, so we
> fall
> back to using the user's cred and the filesystem's auth flavor in this
> case.
>
> We run into another problem when running against linux nfs servers -
> they return NFS4ERR_WRONGSEC when using integrity auth flavor (unless
> the
> mount is also that flavor) even though that is not a valid error for
> SECINFO*. Even though it's against spec, handle WRONGSEC errors on
> SECINFO_NO_NAME by falling back to using the user cred and the
> filesystem's auth flavor.
>
> Signed-off-by: Weston Andros Adamson <dros@netapp.com>
> ---
>
> This patch goes along with yesterday's SECINFO patch
>
> fs/nfs/nfs4proc.c | 41 +++++++++++++++++++++++++++++++++++++----
> 1 file changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index ab1461e..74b37f5 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -7291,7 +7291,8 @@ out:
> */
> static int
> _nfs41_proc_secinfo_no_name(struct nfs_server *server, struct nfs_fh
> *fhandle,
> - struct nfs_fsinfo *info, struct nfs4_secinfo_flavors *flavors)
> + struct nfs_fsinfo *info,
> + struct nfs4_secinfo_flavors *flavors, bool use_integrity)
> {
> struct nfs41_secinfo_no_name_args args = {
> .style = SECINFO_STYLE_CURRENT_FH,
> @@ -7304,8 +7305,23 @@ _nfs41_proc_secinfo_no_name(struct nfs_server
> *server, struct nfs_fh *fhandle,
> .rpc_argp = &args,
> .rpc_resp = &res,
> };
> - return nfs4_call_sync(server->nfs_client->cl_rpcclient, server,
> &msg,
> - &args.seq_args, &res.seq_res, 0);
> + struct rpc_clnt *clnt = server->client;
> + int status;
> +
> + if (use_integrity) {
> + clnt = server->nfs_client->cl_rpcclient;
> + msg.rpc_cred = nfs4_get_clid_cred(server->nfs_client);
> + }
> +
> + dprintk("--> %s\n", __func__);
> + status = nfs4_call_sync(clnt, server, &msg, &args.seq_args,
> + &res.seq_res, 0);
> + dprintk("<-- %s status=%d\n", __func__, status);
> +
> + if (msg.rpc_cred)
> + put_rpccred(msg.rpc_cred);
> +
> + return status;
> }
>
> static int
> @@ -7315,7 +7331,24 @@ nfs41_proc_secinfo_no_name(struct nfs_server
> *server, struct nfs_fh *fhandle,
> struct nfs4_exception exception = { };
> int err;
> do {
> - err = _nfs41_proc_secinfo_no_name(server, fhandle, info, flavors);
> + /* first try using integrity protection */
> + err = -NFS4ERR_WRONGSEC;
> +
> + /* try to use integrity protection with machine cred */
> + if (_nfs4_is_integrity_protected(server->nfs_client))
> + err = _nfs41_proc_secinfo_no_name(server, fhandle, info,
> + flavors, true);
> +
> + /*
> + * if unable to use integrity protection, or SECINFO with
> + * integrity protection returns NFS4ERR_WRONGSEC (which is
> + * disallowed by spec, but exists in deployed servers) use
> + * the current filesystem's rpc_client and the user cred.
> + */
> + if (err == -NFS4ERR_WRONGSEC)
> + err = _nfs41_proc_secinfo_no_name(server, fhandle, info,
> + flavors, false);
> +
> switch (err) {
> case 0:
> case -NFS4ERR_WRONGSEC:
> --
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI 48104
http://linuxbox.com
tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309
next parent reply other threads:[~2013-09-04 16:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <983545972.85.1378311975965.JavaMail.root@thunderbeast.private.linuxbox.com>
2013-09-04 16:29 ` Matt W. Benjamin [this message]
2013-09-04 16:53 ` [PATCH] NFSv4: use mach cred for SECINFO_NO_NAME w/ integrity Adamson, Dros
2013-09-05 12:50 ` Matt W. Benjamin
2013-09-05 15:26 ` Adamson, Dros
2013-09-04 16:13 Weston Andros Adamson
2013-09-04 16:24 ` Myklebust, Trond
2013-09-04 16:48 ` Adamson, Dros
2013-09-05 0:45 ` Myklebust, Trond
2013-09-05 14:07 ` Dr James Bruce Fields
2013-09-05 15:17 ` Adamson, Dros
2013-09-05 15:31 ` Dr James Bruce Fields
2013-09-05 17:05 ` Adamson, Dros
2013-09-05 17:22 ` Dr James Bruce Fields
2013-09-05 17:25 ` Myklebust, Trond
2013-09-05 18:31 ` Adamson, Dros
2013-09-05 20:40 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1816381628.87.1378312148730.JavaMail.root@thunderbeast.private.linuxbox.com \
--to=matt@linuxbox.com \
--cc=Trond.Myklebust@netapp.com \
--cc=dros@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.