From: "J. Bruce Fields" <bfields@fieldses.org>
To: Sven Geggus <lists@fuchsschwanzdomain.de>
Cc: linux-nfs@vger.kernel.org
Subject: Re: Kerberized NFS-Server Problem still present in 3.10.0-rc2
Date: Thu, 20 Jun 2013 10:52:09 -0400 [thread overview]
Message-ID: <20130620145209.GC11728@fieldses.org> (raw)
In-Reply-To: <20130620144955.GB11728@fieldses.org>
On Thu, Jun 20, 2013 at 10:49:55AM -0400, J. Bruce Fields wrote:
> On Thu, Jun 20, 2013 at 10:03:55AM +0200, Sven Geggus wrote:
> > J. Bruce Fields schrieb am Mittwoch, den 19. Juni um 23:34 Uhr:
> >
> > > Apologies, I don't remember the previous discussion, so, could you
> > > summarize for me?
> >
> > Shure!
> > My original bug-report ist here:
> > http://www.spinics.net/lists/linux-nfs/msg37454.html
> >
> > > - you're able to reproduce/not reproduce the problem by changing
> > > *only* the kernel on the nfs server between 3.8.x and
> > > 3.10.0-rc2 ?
> >
> > Exactly. See also the Postings of Richard van den Toorn on the list.
> >
> > Summary: Mount is locking when upgrading from 3.8.x to 3.9.x
> >
> > Unfortunately I was unable to do a git bisect because somewhere on the way
> > the behaviour changed from locking to "permission denied".
> >
> > If you give me a hint if this behaviour should be marked as good or bad I
> > can continue bisecting!
> >
> > > - have you figured out exactly where the failure happens?:
> >
> > No because I have not been able to do git bisect to the end.
> >
> > > - which version of NFS are you using?
> >
> > NFS4 with Kerberos authentication.
>
> What happens with NFSv3?
>
> > > Also if you haven't already it would be useful to know at exactly which
> > > step of the process it's failing. As a first step running wireshark on
> > > the traffic between client and server and looking for a NULL
> > > init_sec_context rpc call and seeing whether it succeeds or not, would
> > > be useful.
> >
> > I already posted a wireshark dump:
> > http://www.spinics.net/lists/linux-nfs/msg37472.html
>
> So it looks it did a null init_sec_context establishment and then the
> server didn't reply to the first rpc call using the new context. But
> it's hard to be sure without more details--could I get the binary dump?
>
> That might be explained by the problem fixed by
> 3c34ae11fac3b30629581d0bfaf80f58e82cfbfb "nfsd: fix krb5 handling of
> anonymous principals", but that was already in v3.9.
Hm, or I wonder if 8b5309d41751b8a086d8e7a43abe37d9ff24559d "svcrpc: fix
failures to handle -1 uid's and gid's" (appended) would help.
--b.
commit 8b5309d41751b8a086d8e7a43abe37d9ff24559d
Author: J. Bruce Fields <bfields@redhat.com>
Date: Fri May 24 17:24:34 2013 -0400
svcrpc: fix failures to handle -1 uid's and gid's
As of f025adf191924e3a75ce80e130afcd2485b53bb8 "sunrpc: Properly decode
kuids and kgids in RPC_AUTH_UNIX credentials" any rpc containing a -1
(0xffff) uid or gid would fail with a badcred error.
Reported symptoms were xmbc clients failing on upgrade of the NFS
server; examination of the network trace showed them sending -1 as the
gid.
Reported-by: Julian Sikorski <belegdol@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
diff --git a/net/sunrpc/svcauth_unix.c b/net/sunrpc/svcauth_unix.c
index c3f9e1e..06bdf5a 100644
--- a/net/sunrpc/svcauth_unix.c
+++ b/net/sunrpc/svcauth_unix.c
@@ -810,11 +810,15 @@ svcauth_unix_accept(struct svc_rqst *rqstp, __be32 *authp)
goto badcred;
argv->iov_base = (void*)((__be32*)argv->iov_base + slen); /* skip machname */
argv->iov_len -= slen*4;
-
+ /*
+ * Note: we skip uid_valid()/gid_valid() checks here for
+ * backwards compatibility with clients that use -1 id's.
+ * Instead, -1 uid or gid is later mapped to the
+ * (export-specific) anonymous id by nfsd_setuser.
+ * Supplementary gid's will be left alone.
+ */
cred->cr_uid = make_kuid(&init_user_ns, svc_getnl(argv)); /* uid */
cred->cr_gid = make_kgid(&init_user_ns, svc_getnl(argv)); /* gid */
- if (!uid_valid(cred->cr_uid) || !gid_valid(cred->cr_gid))
- goto badcred;
slen = svc_getnl(argv); /* gids length */
if (slen > 16 || (len -= (slen + 2)*4) < 0)
goto badcred;
@@ -823,8 +827,6 @@ svcauth_unix_accept(struct svc_rqst *rqstp, __be32 *authp)
return SVC_CLOSE;
for (i = 0; i < slen; i++) {
kgid_t kgid = make_kgid(&init_user_ns, svc_getnl(argv));
- if (!gid_valid(kgid))
- goto badcred;
GROUP_AT(cred->cr_group_info, i) = kgid;
}
if (svc_getu32(argv) != htonl(RPC_AUTH_NULL) || svc_getu32(argv) != 0) {
next prev parent reply other threads:[~2013-06-20 14:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 13:47 Kerberized NFS-Server Problem still present in 3.10.0-rc2 Sven Geggus
2013-06-19 21:34 ` J. Bruce Fields
2013-06-20 8:03 ` Sven Geggus
2013-06-20 12:09 ` Sven Geggus
2013-06-20 14:49 ` J. Bruce Fields
2013-06-20 14:52 ` J. Bruce Fields [this message]
2013-06-21 8:32 ` Sven Geggus
2013-06-24 21:54 ` J. Bruce Fields
2013-06-25 9:46 ` Sven Geggus
2013-07-01 12:09 ` Sven Geggus
[not found] ` <20130701205234.GF19945@fieldses.org>
2013-07-02 8:05 ` Sven Geggus
[not found] ` <20130705181859.GA8288@fieldses.org>
[not found] ` <20130705203435.GE8288@fieldses.org>
2013-07-08 8:08 ` Sven Geggus
2013-07-08 13:35 ` J. Bruce Fields
2013-07-08 15:54 ` Sven Geggus
2013-07-08 19:41 ` J. Bruce Fields
2013-07-09 16:03 ` Sven Geggus
2013-07-09 16:57 ` J. Bruce Fields
2013-07-09 17:23 ` Chuck Lever
2013-07-10 7:55 ` Sven Geggus
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=20130620145209.GC11728@fieldses.org \
--to=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lists@fuchsschwanzdomain.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).