Return-Path: Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]:51826 "EHLO elasmtp-spurfowl.atl.sa.earthlink.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756444AbbIVDEl convert rfc822-to-8bit (ORCPT ); Mon, 21 Sep 2015 23:04:41 -0400 References: <1442429367.24127.6.camel@localhost.localdomain> <08D9E2B0-B4A8-4DF0-9BB7-B19B2D260E97@oracle.com> <001a01d0f0c7$ca84e6d0$5f8eb470$@mindspring.com> <3E2CC450-BB4D-4F08-957D-EB78FE3665BE@oracle.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Type: text/plain; charset=utf-8 Message-Id: Cc: Chuck Lever , Linux NFS Mailing List From: Frank Filz Subject: Re: [PATCH] Use a separate superblock if mount requires a different security flavor Date: Mon, 21 Sep 2015 20:03:59 -0700 To: Trond Myklebust Sender: linux-nfs-owner@vger.kernel.org List-ID: I'll see what happens with mounting / and then navigating into the two exports. My gut feel is my patch will actually make that work but I acknowledge the automatic mounts that will occur might follow a different path that isn't helped by my patch. I can also try and find out what freebsd client does. I also agree with Chuck that some understanding if this configuration is something sysadmins genuinely expect to work (as opposed to QA folks trying the scenario because no documentation says it isn't supported). If we decide it shouldn't be supported then we should consider making server side changes. Frank Sent from my iPhone On Sep 21, 2015, at 5:43 PM, Trond Myklebust wrote: > On Mon, Sep 21, 2015 at 7:10 PM, Chuck Lever wrote: >> >>> On Sep 17, 2015, at 11:01 AM, Chuck Lever wrote: >>> >>> >>> On Sep 16, 2015, at 11:32 PM, Trond Myklebust wrote: >>> >>>> On Wed, Sep 16, 2015 at 5:36 PM, Frank Filz wrote: >>>>>> On Wed, Sep 16, 2015 at 4:55 PM, Chuck Lever >>>>>> wrote: >>>>>>> >>>>>>> On Sep 16, 2015, at 4:52 PM, Trond Myklebust >>>>>> wrote: >>>>>>> >>>>>>>> On Wed, Sep 16, 2015 at 2:49 PM, Frank Filz >>>>>> wrote: >>>>>>>>> If a server has two exports from the same filesystem but with >>>>>>>>> different security flavors allowed, when the client mounts first one >>>>>>>>> and then the second, the same super block was being used. This >>>>>>>>> resulted in the security flavor for the first export being applied >>>>>>>>> to access to the second export. >>>>>>>>> >>>>>>>>> The fix is simply to check the security flavor of the nfs_server >>>>>>>>> temporarily constructed for the second mount within >>>>>> nfs_compare_super. >>>>>>>>> >>>>>>>>> Signed-off-by: Frank S. Filz >>>>>>>>> --- >>>>>>>>> fs/nfs/super.c | 3 +++ >>>>>>>>> 1 file changed, 3 insertions(+) >>>>>>>>> >>>>>>>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c index 084af10..44d60f1 >>>>>>>>> 100644 >>>>>>>>> --- a/fs/nfs/super.c >>>>>>>>> +++ b/fs/nfs/super.c >>>>>>>>> @@ -2455,6 +2455,9 @@ static int nfs_compare_super(struct >>>>>>>>> super_block *sb, void *data) >>>>>>>>> struct nfs_server *server = sb_mntdata->server, *old = >>>>>>>>> NFS_SB(sb); >>>>>>>>> int mntflags = sb_mntdata->mntflags; >>>>>>>>> >>>>>>>>> + if(old->client->cl_auth->au_flavor >>>>>>>>> + != server->client->cl_auth->au_flavor) >>>>>>>>> + return 0; >>>>>>>> >>>>>>>> Isn't this check already being performed in >>>>>>>> nfs_compare_mount_options()? As far as I can see, the difference is >>>>>>>> that you are checking unconditionally, whereas >>>>>>>> nfs_compare_mount_options only does so if there was a 'sec=' line >>>>>>>> specified in the mount options. >>>>>>> >>>>>>> Right. If the user doesn't provide a sec=, the security flavor is >>>>>>> autonegotiated. In the case Frank describes, there are two directories >>>>>>> shared on the server, each from the same FSID but using distinct >>>>>>> security policies. >>>>>>> >>>>>>> So the mount options comparison is inadequate if no sec= is specified >>>>>>> on the mount command line. >>>>>> >>>>>> We don't claim to support autonegotiation of multiple security policies per >>>>>> filesystem, in general. We only claim to support one auth flavour per super >>>>>> block. >>>>>> >>>>>> If I understand you correctly, you are knowingly trying to work around that >>>>>> limitation by performing multiple mounts of the same filesystem and force it >>>>>> to use multiple super blocks. Why can't you then also specify the 'sec='? >>>>> >>>>> I see that point, but why not just make this case work smoothly rather than force the user to go back and specify -o sec on the mount? >>>> >>>> The main issue is that it violates the policy that we must try our >>>> best not to set up situations where the client has cache consistency >>>> issues due to the existence of multiple superblocks that all have page >>>> caches for the same file. >>> >>> The parts of the physical FS's namespace that are accessible >>> by each security flavor are disjoint. Aside from hardlinks, is >>> there any possibility for cache aliasing in this scenario? >>> >>> >>>>> Actually all that is necessary is SOME difference in mount options (or use -o nosharedcache, which could be used on all the mounts so all can have the same mount options...) and allow security negotiation to work. >>>> >>>> I'd expect there to be no problems if the admin specifies -o >>>> nosharedcache. Please do let me know if that fails to work. >>>> >>>>> An interesting question is if there are any servers out there that don't typically provide different FSID for different portions of the namespace, but also provide a mechanism to specify different security policies for different portions of the namespace? >>>> >>>> That sort of situation is difficult to manage. >>> >>> But appears to be allowed by Solaris, and likely also by Linux >>> and Ganesha. I think we are going to have to consider it, >>> particularly if there is no prohibition against it in the RFCs. >> >> It is certainly possible to document best practices or >> add admin UI limits to prevent servers from being >> configured this way. >> >> Meanwhile, the Linux client does allow mounting such >> exports when both mounts specify unique “sec=“. If this >> is a dangerous or unsupported scenario, perhaps this >> should be disallowed somehow. >> >> When security is negotiated, the second mount is not >> allowed. It could display an informative error message >> when if fails. > > My main worry with the patch you proposed is that we're only > considering a small part of the problem here, namely what happens on > mount. > What if the user were to mount '/' instead of the particular path you > chose, and then simply walk down to the problematic directory? As far > as I can see, that will fail just as badly both with and without this > patch. Why would users expect that behaviour to be any different to > the new mount behaviour? > > IOW: what is the full set of expectations would we be setting by > applying the patch, and what is the rationale for changing some > behaviour, but not all? > > Also, while I know that the Linux client has never supported this > behaviour. What do the Solaris and FreeBSD clients do, and what are > their limitations? > > Cheers > Trond