linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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) {

  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).