Subject: Re: MNT_NOSHARE for non-exportable fs [was: Removing tmpfs' experimental
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Cary G. Gray <Cary.G.Gray@wheaton.edu>
List: tech-kern
Date: 10/25/2006 11:00:47
I think that two different issues are getting equated here.  One of them 
is the "do I _permit_ this to be exported?" question.  That is really a
question about access control, and making it work depends on getting all 
'exporting' software to honor it.  Enforcing it by some other means has to 
be part of the security model.

The other issue is very close--but not quite identical--to "is it 
_possible_ to export this via NFS?"  I'd argue that the underlying issue 
is whether the filesystem meaningfully supports persistent, unique, 
filehandles.  NFS requires that capability; other imaginable uses of a 
file store might want it, too.  Note that this is a question of 
functionality, not access control.  And it is about filehandles, not 
exporting.

If we're sticking to this second issue, there are to interface-related 
questions:

1) What is the appropriate means for finding out about the limitations of 
a particular filesystem?  (And how does, e.g., NFS export check them?)

2) If there is a filesystem that can provide a particular capability that 
is not always needed, but doing so imposes unacceptable overhead--unless 
one needs that capability--how (if at all) do we specify whether to 
provide it?

I think that the '-x' option for NFS (client) mount is an example of #2.
I'm not aware of (nor have I hunted for) examples of #1.

 	Cary Gray

On Wed, 25 Oct 2006, Bill Studenmund wrote:
> On Wed, Oct 25, 2006 at 09:11:50PM +0900, YAMAMOTO Takashi wrote:
>>>> - why "share" rather than "export"?
>>>
>>> I chose "share" because "export" is too tightly coupled with NFS. However, I'm
>>> sure my point of view can be swayed ;-)
>>
>> it's actually tightly coupled with nfs, isn't it?
>> eg. how can it prevent smbd or apache from exporting the filesystem?
...
>
> I think it depends on the exact semantics we are trying to expose. A "No
> one can access this mount point now" option is muddled, and I think
> incorrect (and not what this code does).
>
> I think a "I don't want this file system exported/shared EVER" semantic
> can make sense as a mount option. The administrator can add the flag in
> /etc/fstab, and then nothing else in the system will (or should) let it
> get exported.