- 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 <[email protected]>
---
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
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 <[email protected]>
>
> ---
>
> 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
On Mon, Feb 16, 2015 at 3:17 PM, J. Bruce Fields <[email protected]> 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 <[email protected]>
>>
>> ---
>>
>> 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.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
[email protected]
On Mon, 16 Feb 2015 18:06:06 -0500 Trond Myklebust
<[email protected]> wrote:
> On Mon, Feb 16, 2015 at 3:17 PM, J. Bruce Fields <[email protected]> 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 <[email protected]>
> >>
> >> ---
> >>
> >> 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 Mon, 16 Feb 2015 15:17:51 -0500 [email protected] (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 <[email protected]>
> >
> > ---
> >
> > 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 Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote:
> On Mon, 16 Feb 2015 15:17:51 -0500 [email protected] (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 <[email protected]>
> > >
> > > ---
> > >
> > > 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.
On Tue, 17 Feb 2015 20:54:32 -0500 "J. Bruce Fields" <[email protected]>
wrote:
> On Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote:
> > On Mon, 16 Feb 2015 15:17:51 -0500 [email protected] (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 <[email protected]>
> > > >
> > > > ---
> > > >
> > > > 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" <[email protected]>
> wrote:
>
> > On Wed, Feb 18, 2015 at 12:41:01PM +1100, NeilBrown wrote:
> > > On Mon, 16 Feb 2015 15:17:51 -0500 [email protected] (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 <[email protected]>
> > > > >
> > > > > ---
> > > > >
> > > > > 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.
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 <[email protected]>
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
>