| Message ID | 20150216122107.4bfd4225@notabene.brown (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > > > - note that 'nohide' is irrelevant for NFSv4 > - note that children on a 'crossmnt' filesystem cannot be unexported > - note that 'nocrossmnt' is a valid option, but probably not useful. > > Signed-off-by: NeilBrown <neilb@suse.de> > > --- > > I wonder if we should add a new option, e.g. "noaccess" so that children > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > know about this. It would just tell mountd to refuse to export that > filesystem even if the parent was "crossmnt". > ?? Seems logical enough, but I can't recall seeing requests for it, and the options here already seem complicated enough. In theory something like that could also be done with namespaces. (So, run mountd in a separate mount namespace that lacks those children.) --b. > > NeilBrown > > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man > index 3d974d92a729..88d9fbebe386 100644 > --- a/utils/exportfs/exports.man > +++ b/utils/exportfs/exports.man > @@ -218,16 +218,46 @@ This option can be very useful in some situations, but it should be > used with due care, and only after confirming that the client system > copes with the situation effectively. > > -The option can be explicitly disabled with > +The option can be explicitly disabled for NFSv2 and NFSv3 with > .IR hide . > + > +This option is not relevant when NFSv4 is use. NFSv4 never hides > +subordinate filesystems. Any filesystem that is exported will be > +visible where expected when using NFSv4. > .TP > -.IR crossmnt > +.I crossmnt > This option is similar to > .I nohide > -but it makes it possible for clients to move from the filesystem marked > -with crossmnt to exported filesystems mounted on it. Thus when a child > -filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has > -the same effect as setting "nohide" on B. > +but it makes it possible for clients to access all filesystems mounted > +on a filesystem marked with > +.IR crossmnt . > +Thus when a child filesystem "B" is mounted on a parent "A", setting > +crossmnt on "A" has a similar effect to setting "nohide" on B. > + > +With > +.I nohide > +the child filesystem needs to be explicitly exported. With > +.I crossmnt > +it need not. If a child of a > +.I crossmnt > +file is not explicitly exported, then it will be implicitly exported > +with the same export options as the parent, except for > +.IR fsid= . > +This makes it impossible to > +.B not > +export a child of a > +.I crossmnt > +filesystem. If some but not all subordinate filesystems of a parent > +are to be exported, then they must be explicitly exported and the > +parent should not have > +.I crossmnt > +set. > + > +The > +.I nocrossmnt > +option can explictly disable > +.I crossmnt > +if it was previously set. This is rarely useful. > .TP > .IR no_subtree_check > This option disables subtree checking, which has mild security -- 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
On Mon, Feb 16, 2015 at 3:17 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: >> >> >> - note that 'nohide' is irrelevant for NFSv4 >> - note that children on a 'crossmnt' filesystem cannot be unexported >> - note that 'nocrossmnt' is a valid option, but probably not useful. >> >> Signed-off-by: NeilBrown <neilb@suse.de> >> >> --- >> >> I wonder if we should add a new option, e.g. "noaccess" so that children >> of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to >> know about this. It would just tell mountd to refuse to export that >> filesystem even if the parent was "crossmnt". >> ?? > > Seems logical enough, but I can't recall seeing requests for it, and > the options here already seem complicated enough. > > In theory something like that could also be done with namespaces. (So, > run mountd in a separate mount namespace that lacks those children.) Agreed. It seems unnecessarily complicated to add yet another option to the crossmnt/nohide saga. If the "nohide" documentation is too complex, then we should rather aim to improve that documentation.
On Mon, 16 Feb 2015 15:17:51 -0500 bfields@fieldses.org (J. Bruce Fields) wrote: > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > > > > > > - note that 'nohide' is irrelevant for NFSv4 > > - note that children on a 'crossmnt' filesystem cannot be unexported > > - note that 'nocrossmnt' is a valid option, but probably not useful. > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > --- > > > > I wonder if we should add a new option, e.g. "noaccess" so that children > > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > > know about this. It would just tell mountd to refuse to export that > > filesystem even if the parent was "crossmnt". > > ?? > > Seems logical enough, but I can't recall seeing requests for it, and > the options here already seem complicated enough. I haven't seem requests myself. Just rumours of 'nohide' not working with NFSv4, which seems to suggest that someone wants something like that. But I cannot find a clear source. Maybe: http://ubuntuforums.org/showthread.php?t=2152643 http://ubuntuforums.org/showthread.php?t=1603881 > > In theory something like that could also be done with namespaces. (So, > run mountd in a separate mount namespace that lacks those children.) Do any of the NFS man pages need to be updated to say something about namespaces? NeilBrown
On Mon, 16 Feb 2015 18:06:06 -0500 Trond Myklebust <trond.myklebust@primarydata.com> wrote: > On Mon, Feb 16, 2015 at 3:17 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > >> > >> > >> - note that 'nohide' is irrelevant for NFSv4 > >> - note that children on a 'crossmnt' filesystem cannot be unexported > >> - note that 'nocrossmnt' is a valid option, but probably not useful. > >> > >> Signed-off-by: NeilBrown <neilb@suse.de> > >> > >> --- > >> > >> I wonder if we should add a new option, e.g. "noaccess" so that children > >> of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > >> know about this. It would just tell mountd to refuse to export that > >> filesystem even if the parent was "crossmnt". > >> ?? > > > > Seems logical enough, but I can't recall seeing requests for it, and > > the options here already seem complicated enough. > > > > In theory something like that could also be done with namespaces. (So, > > run mountd in a separate mount namespace that lacks those children.) > > Agreed. It seems unnecessarily complicated to add yet another option > to the crossmnt/nohide saga. If the "nohide" documentation is too > complex, then we should rather aim to improve that documentation. > Yes - improving the documentation was my first step, hence this patch. Writing that documentation lead me to see that a particular configuration was impossible - hence the question. I have no strong desire for a change, and that seems to be common among others, so let's just drop it. Thanks, NeilBrown
On Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote: > On Mon, 16 Feb 2015 15:17:51 -0500 bfields@fieldses.org (J. Bruce Fields) > wrote: > > > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > > > > > > > > > - note that 'nohide' is irrelevant for NFSv4 > > > - note that children on a 'crossmnt' filesystem cannot be unexported > > > - note that 'nocrossmnt' is a valid option, but probably not useful. > > > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > > > --- > > > > > > I wonder if we should add a new option, e.g. "noaccess" so that children > > > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > > > know about this. It would just tell mountd to refuse to export that > > > filesystem even if the parent was "crossmnt". > > > ?? > > > > Seems logical enough, but I can't recall seeing requests for it, and > > the options here already seem complicated enough. > > I haven't seem requests myself. Just rumours of 'nohide' not working with > NFSv4, which seems to suggest that someone wants something like that. > But I cannot find a clear source. > > Maybe: > > http://ubuntuforums.org/showthread.php?t=2152643 > http://ubuntuforums.org/showthread.php?t=1603881 > > > > > > In theory something like that could also be done with namespaces. (So, > > run mountd in a separate mount namespace that lacks those children.) > > Do any of the NFS man pages need to be updated to say something about > namespaces? Maybe just a note in the rpc.mountd man page that export paths are all with respect to the mount namespace rpc.mountd is running in? --b. -- 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
On Tue, 17 Feb 2015 20:54:32 -0500 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote: > > On Mon, 16 Feb 2015 15:17:51 -0500 bfields@fieldses.org (J. Bruce Fields) > > wrote: > > > > > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > > > > > > > > > > > > - note that 'nohide' is irrelevant for NFSv4 > > > > - note that children on a 'crossmnt' filesystem cannot be unexported > > > > - note that 'nocrossmnt' is a valid option, but probably not useful. > > > > > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > > > > > --- > > > > > > > > I wonder if we should add a new option, e.g. "noaccess" so that children > > > > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > > > > know about this. It would just tell mountd to refuse to export that > > > > filesystem even if the parent was "crossmnt". > > > > ?? > > > > > > Seems logical enough, but I can't recall seeing requests for it, and > > > the options here already seem complicated enough. > > > > I haven't seem requests myself. Just rumours of 'nohide' not working with > > NFSv4, which seems to suggest that someone wants something like that. > > But I cannot find a clear source. > > > > Maybe: > > > > http://ubuntuforums.org/showthread.php?t=2152643 > > http://ubuntuforums.org/showthread.php?t=1603881 > > > > > > > > > > In theory something like that could also be done with namespaces. (So, > > > run mountd in a separate mount namespace that lacks those children.) > > > > Do any of the NFS man pages need to be updated to say something about > > namespaces? > > Maybe just a note in the rpc.mountd man page that export paths are all > with respect to the mount namespace rpc.mountd is running in? > I assume that implies that there can only ever be one rpc.mountd running? I haven't really been following, but I assumed we would end up with a different rpc.mountd in each of several different namespaces, each one seeing a different cache through a differently configured /proc.. And somehow there would be different nfsds in different network namespaces, each tied to a filesystem namespace ... or something. I guess that isn't want is really happening? Thanks, NeilBrown
On Wed, Feb 18, 2015 at 01:09:49PM +1100, NeilBrown wrote: > On Tue, 17 Feb 2015 20:54:32 -0500 "J. Bruce Fields" <bfields@fieldses.org> > wrote: > > > On Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote: > > > On Mon, 16 Feb 2015 15:17:51 -0500 bfields@fieldses.org (J. Bruce Fields) > > > wrote: > > > > > > > On Mon, Feb 16, 2015 at 12:21:07PM +1100, NeilBrown wrote: > > > > > > > > > > > > > > > - note that 'nohide' is irrelevant for NFSv4 > > > > > - note that children on a 'crossmnt' filesystem cannot be unexported > > > > > - note that 'nocrossmnt' is a valid option, but probably not useful. > > > > > > > > > > Signed-off-by: NeilBrown <neilb@suse.de> > > > > > > > > > > --- > > > > > > > > > > I wonder if we should add a new option, e.g. "noaccess" so that children > > > > > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > > > > > know about this. It would just tell mountd to refuse to export that > > > > > filesystem even if the parent was "crossmnt". > > > > > ?? > > > > > > > > Seems logical enough, but I can't recall seeing requests for it, and > > > > the options here already seem complicated enough. > > > > > > I haven't seem requests myself. Just rumours of 'nohide' not working with > > > NFSv4, which seems to suggest that someone wants something like that. > > > But I cannot find a clear source. > > > > > > Maybe: > > > > > > http://ubuntuforums.org/showthread.php?t=2152643 > > > http://ubuntuforums.org/showthread.php?t=1603881 > > > > > > > > > > > > > > In theory something like that could also be done with namespaces. (So, > > > > run mountd in a separate mount namespace that lacks those children.) > > > > > > Do any of the NFS man pages need to be updated to say something about > > > namespaces? > > > > Maybe just a note in the rpc.mountd man page that export paths are all > > with respect to the mount namespace rpc.mountd is running in? > > > > I assume that implies that there can only ever be one rpc.mountd running? > > I haven't really been following, but I assumed we would end up with a > different rpc.mountd in each of several different namespaces, each one seeing > a different cache through a differently configured /proc.. Right, so in the simple case there's one rpc.mountd, and export paths are interpreted with respect to that rpc.mountd's namespace. If you have multiple network namespaces, then you can independently start and stop nfsd's in each network namespace, each talking to its own rpc.mountd. > And somehow there would be different nfsds in different network namespaces, > each tied to a filesystem namespace ... or something. > > > I guess that isn't want is really happening? So, yes, that's the idea. NFSv4 doesn't work because of the unfinished usermode helper containerization stuff Ian Kent's working on. And I don't think anyone's really used any of this so there may be other lurking bugs. May still make sense to document what we have so far, though. --b. -- 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
On 02/15/2015 08:21 PM, NeilBrown wrote: > > > - note that 'nohide' is irrelevant for NFSv4 > - note that children on a 'crossmnt' filesystem cannot be unexported > - note that 'nocrossmnt' is a valid option, but probably not useful. > > Signed-off-by: NeilBrown <neilb@suse.de> Committed! steved. > > --- > > I wonder if we should add a new option, e.g. "noaccess" so that children > of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to > know about this. It would just tell mountd to refuse to export that > filesystem even if the parent was "crossmnt". > ?? > > NeilBrown > > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man > index 3d974d92a729..88d9fbebe386 100644 > --- a/utils/exportfs/exports.man > +++ b/utils/exportfs/exports.man > @@ -218,16 +218,46 @@ This option can be very useful in some situations, but it should be > used with due care, and only after confirming that the client system > copes with the situation effectively. > > -The option can be explicitly disabled with > +The option can be explicitly disabled for NFSv2 and NFSv3 with > .IR hide . > + > +This option is not relevant when NFSv4 is use. NFSv4 never hides > +subordinate filesystems. Any filesystem that is exported will be > +visible where expected when using NFSv4. > .TP > -.IR crossmnt > +.I crossmnt > This option is similar to > .I nohide > -but it makes it possible for clients to move from the filesystem marked > -with crossmnt to exported filesystems mounted on it. Thus when a child > -filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has > -the same effect as setting "nohide" on B. > +but it makes it possible for clients to access all filesystems mounted > +on a filesystem marked with > +.IR crossmnt . > +Thus when a child filesystem "B" is mounted on a parent "A", setting > +crossmnt on "A" has a similar effect to setting "nohide" on B. > + > +With > +.I nohide > +the child filesystem needs to be explicitly exported. With > +.I crossmnt > +it need not. If a child of a > +.I crossmnt > +file is not explicitly exported, then it will be implicitly exported > +with the same export options as the parent, except for > +.IR fsid= . > +This makes it impossible to > +.B not > +export a child of a > +.I crossmnt > +filesystem. If some but not all subordinate filesystems of a parent > +are to be exported, then they must be explicitly exported and the > +parent should not have > +.I crossmnt > +set. > + > +The > +.I nocrossmnt > +option can explictly disable > +.I crossmnt > +if it was previously set. This is rarely useful. > .TP > .IR no_subtree_check > This option disables subtree checking, which has mild security > -- 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
diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man index 3d974d92a729..88d9fbebe386 100644 --- a/utils/exportfs/exports.man +++ b/utils/exportfs/exports.man @@ -218,16 +218,46 @@ This option can be very useful in some situations, but it should be used with due care, and only after confirming that the client system copes with the situation effectively. -The option can be explicitly disabled with +The option can be explicitly disabled for NFSv2 and NFSv3 with .IR hide . + +This option is not relevant when NFSv4 is use. NFSv4 never hides +subordinate filesystems. Any filesystem that is exported will be +visible where expected when using NFSv4. .TP -.IR crossmnt +.I crossmnt This option is similar to .I nohide -but it makes it possible for clients to move from the filesystem marked -with crossmnt to exported filesystems mounted on it. Thus when a child -filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has -the same effect as setting "nohide" on B. +but it makes it possible for clients to access all filesystems mounted +on a filesystem marked with +.IR crossmnt . +Thus when a child filesystem "B" is mounted on a parent "A", setting +crossmnt on "A" has a similar effect to setting "nohide" on B. + +With +.I nohide +the child filesystem needs to be explicitly exported. With +.I crossmnt +it need not. If a child of a +.I crossmnt +file is not explicitly exported, then it will be implicitly exported +with the same export options as the parent, except for +.IR fsid= . +This makes it impossible to +.B not +export a child of a +.I crossmnt +filesystem. If some but not all subordinate filesystems of a parent +are to be exported, then they must be explicitly exported and the +parent should not have +.I crossmnt +set. + +The +.I nocrossmnt +option can explictly disable +.I crossmnt +if it was previously set. This is rarely useful. .TP .IR no_subtree_check This option disables subtree checking, which has mild security
- note that 'nohide' is irrelevant for NFSv4 - note that children on a 'crossmnt' filesystem cannot be unexported - note that 'nocrossmnt' is a valid option, but probably not useful. Signed-off-by: NeilBrown <neilb@suse.de> --- I wonder if we should add a new option, e.g. "noaccess" so that children of a "crossmnt" filesystem can be hidden. The kernel wouldn't need to know about this. It would just tell mountd to refuse to export that filesystem even if the parent was "crossmnt". ?? NeilBrown