Subject: Re: MNT_NOSHARE for non-exportable fs [was: Removing tmpfs' experimental status
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/25/2006 08:21:35
Content-Type: text/plain; charset=us-ascii
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. Howev=
> > 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?
We teach apache or smbd to look for it?
> > > - what's the point to expose it as a mount option?
> > > sys_mount is not an appropriate interface to control nfs exportabil=
> > > these days. to specify filesystem characteristics,
> > > IMNT_ is more appropriate.
> > I'm exposing it as a mount option so that userland knows it's there. It=
> > clear indicater of _why_ exporting doesn't work, "noshare" (or "noexpor=
> > be seen from the mount options.
> i believe that mount is a wrong way to show this kind of
> filesystem characteristics.
I think it depends on the exact semantics we are trying to expose. A "No=20
one can access this mount point now" option is muddled, and I think=20
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=20
/etc/fstab, and then nothing else in the system will (or should) let it=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----