Return-Path: Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]:50945 "EHLO elasmtp-banded.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbbIORl0 (ORCPT ); Tue, 15 Sep 2015 13:41:26 -0400 From: "Frank Filz" To: "'Chuck Lever'" Cc: "'Linux NFS Mailing List'" References: <7A550B5E-9EAB-4431-BBBA-1C77EE86539F@oracle.com> <019501d0efd4$401f4240$c05dc6c0$@mindspring.com> In-Reply-To: Subject: RE: NFSv4 security negotiation issue Date: Tue, 15 Sep 2015 10:41:08 -0700 Message-ID: <01a301d0efdd$b8106f00$28314d00$@mindspring.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: linux-nfs-owner@vger.kernel.org List-ID: > On Sep 15, 2015, at 12:33 PM, Frank Filz wrote: > > >> We've found an unexpected behavior with mount security negotiation in > >> the current Linux NFS client. > >> > >> Given two real shares on an NFS server: one is a sys-only share, and > >> the other is a krb5-only share. When we try to mount the sys-only > >> share > > without > >> specifying a sec= option, it fails. Specifying sec=sys is successful. > >> > >> What is seen on the wire: > >> > >> 1. The client attempts to access the pseudofs, and negotiates > >> krb5 > >> > >> 2. The client walks down the pseudofs namespace to the sys-only share > >> > >> 3. The client attempts to access the sys-only share with krb5 and > >> gets WRONGSEC > >> > >> 4. The client negotiates sys, and continues setting up the mount > >> > >> 5. nfs_fs_mount_common() invokes nfs_get_root(), but it uses the > >> pseudofs superblock, so it does a GETATTR on the share's root > >> directory > > with > >> krb5, and that fails > >> > >> At this point the client gives up, and the mount attempt fails. > >> > >> We could alter the server to allow a GETATTR with the same flavor as > >> the underlying directory. But seems like the problem is on the > >> client: it > > should > >> use the negotiated flavor that is appropriate to the share, not the > >> flavor appropriate for the pseudofs. > >> > >> Any thoughts? > > > > Hmm, I thought maybe this was a scenario I had not tested, but I think > > I'm misunderstanding the sequence. Could you summarize the ops and > > response for each COMPOUND request? > > There are two shares on the server. > > The share being mounted is /export/CTHON. It is a sys-only share. No "sec=" > option is used on the mount command. The expected outcome is that the > mount will succeed and use sec=sys. > > The share that is not being mounted here is /export/KRB5. > It is shared with at least krb5i, which means the set of flavors the server > accepts for the pseudofs includes both krb5i and sys. > > The client has already negotiated krb5i to access the pseudofs. I see a > PUTROOTFH using krb5i and it is successful. The negotiation is not in the trace > I have. > > I see a number of GETATTRs then a LOOKUP /export, all with krb5i, all > successful. > > Using krb5i, LOOKUP /CTHON, which fails with WRONGSEC. > > Client recovers with SECINFO on /CTHON using krb5i. The server responds > with a list containing just AUTH_UNIX. > > Client tries the LOOKUP /CTHON again, now with sys. It works. > > Similar GETATTR activity using sys as the client mounts this share. > > Then one last GETATTR, this time using krb5i. The FH is the /export/CTHON > directory. This fails with WRONGSEC. > > The attr mask here is Supported Attrs, FH_Expire_type, Link_Support, > Symlink_Support, ACLSupport. This is from nfs4_server_capabilities(), which > is invoked only in nfs4_proc_get_rootfh() and nfs4_proc_get_root(). > > The next operation OTW is a RENEW that happens a minute later.