2009-03-25 18:55:55

by Steve Dickson

[permalink] [raw]
Subject: Making crossmnt a default export option

Hello,

What would be the ramifications of turning on the crossmnt
option on by default? Currently the the default is nocrossmnt.

In my recent work with pseudo exports, it has become very apparent
that having the crossmnt always set, especially with multi file
system exports, allows mount to "just work"!

So historically what is the reason for not allowing the clients
to always cross file systems? Is it a security issue?
And again, what would be the ramifications always allowing, by
default, clients to cross file systems?

steved.



2009-03-25 19:23:46

by Trond Myklebust

[permalink] [raw]
Subject: Re: Making crossmnt a default export option

On Wed, 2009-03-25 at 14:53 -0400, Steve Dickson wrote:
> Hello,
>
> What would be the ramifications of turning on the crossmnt
> option on by default? Currently the the default is nocrossmnt.
>
> In my recent work with pseudo exports, it has become very apparent
> that having the crossmnt always set, especially with multi file
> system exports, allows mount to "just work"!
>
> So historically what is the reason for not allowing the clients
> to always cross file systems? Is it a security issue?
> And again, what would be the ramifications always allowing, by
> default, clients to cross file systems?

I think the only real problem would be that Solaris tends to get very
confused when you do. As Benny pointed out, the original NFSv2 and NFSv3
specs didn't allow you to cross mount points, and so Solaris never got
round to implementing it.
I don't know what the current status is, but the original Solaris 10
NFSv4 client was also incapable of crossing mount points despite the
fact that rfc3530 does support it.

Cheers
Trond


2009-03-25 19:00:08

by Benny Halevy

[permalink] [raw]
Subject: Re: Making crossmnt a default export option

On Mar. 25, 2009, 20:53 +0200, Steve Dickson <[email protected]> wrote:
> Hello,
>
> What would be the ramifications of turning on the crossmnt
> option on by default? Currently the the default is nocrossmnt.
>
> In my recent work with pseudo exports, it has become very apparent
> that having the crossmnt always set, especially with multi file
> system exports, allows mount to "just work"!
>
> So historically what is the reason for not allowing the clients
> to always cross file systems? Is it a security issue?
> And again, what would be the ramifications always allowing, by
> default, clients to cross file systems?

http://www.ietf.org/rfc/rfc1813.txt:
3.3.3 Procedure 3: LOOKUP - Lookup filename
IMPLEMENTATION

At first glance, in the case where what.name refers to a
mount point on the server, two different replies seem
possible. The server can return either the file handle for
the underlying directory that is mounted on or the file
handle of the root of the mounted directory. This
ambiguity is simply resolved. A server will not allow a
LOOKUP operation to cross a mountpoint to the root of a
different filesystem, even if the filesystem is exported.


>
> steved.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2009-03-26 00:36:47

by Spencer

[permalink] [raw]
Subject: Re: Making crossmnt a default export option

On Wed, Mar 25, 2009 at 1:53 PM, Steve Dickson <[email protected]> wrote:
> Hello,
>
> What would be the ramifications of turning on the crossmnt
> option on by default? Currently the the default is nocrossmnt.
>
> In my recent work with pseudo exports, it has become very apparent
> that having the crossmnt always set, especially with multi file
> system exports, allows mount to "just work"!
>
> So historically what is the reason for not allowing the clients
> to always cross file systems? Is it a security issue?
> And again, what would be the ramifications always allowing, by
> default, clients to cross file systems?

As Trond mentioned, the OpenSolaris client doesn't automatically
create mount points when crossing the server's filesystem boundaries
(for NFSv3).
NFSv4 support for that behavior is now present for OpenSolaris.

So the risk is running into clients that don't behave like the Linux
client and then "mv" will not be able to determine the appropriate
behavior when mv'ing files between those filesystems.

Spencer

>
> steved.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

2009-04-01 16:06:27

by J. Bruce Fields

[permalink] [raw]
Subject: Re: Making crossmnt a default export option

On Wed, Mar 25, 2009 at 07:36:45PM -0500, spencer shepler wrote:
> On Wed, Mar 25, 2009 at 1:53 PM, Steve Dickson <[email protected]> wrote:
> > Hello,
> >
> > What would be the ramifications of turning on the crossmnt
> > option on by default? Currently the the default is nocrossmnt.
> >
> > In my recent work with pseudo exports, it has become very apparent
> > that having the crossmnt always set, especially with multi file
> > system exports, allows mount to "just work"!
> >
> > So historically what is the reason for not allowing the clients
> > to always cross file systems? Is it a security issue?
> > And again, what would be the ramifications always allowing, by
> > default, clients to cross file systems?
>
> As Trond mentioned, the OpenSolaris client doesn't automatically
> create mount points when crossing the server's filesystem boundaries
> (for NFSv3).
> NFSv4 support for that behavior is now present for OpenSolaris.
>
> So the risk is running into clients that don't behave like the Linux
> client and then "mv" will not be able to determine the appropriate
> behavior when mv'ing files between those filesystems.

And some applications may be confused when they see different files that
appear to be on the same filesystem but that have different inodes.
Etc.

And this requires people to change their exports. We've done this
before (with sync and subtree_check), but it's something to avoid if at
all possible.

So preserving the current behavior for v2/v3 is important.

--b.