Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Aug 2012 08:59:11 -0400 (EDT)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        d@delphij.net
Cc:        freebsd-fs@FreeBSD.ORG, rmacklem@FreeBSD.org
Subject:   Re: Why vfs_stdcheckexp is a VFS operation?
Message-ID:  <140200696.1251333.1346245151029.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <503D301F.5080607@delphij.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Xin Li wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi,
> 
> We have recently run into a problem with exports(5) and I then read
> the code of mountd(8) as well as sys/kern/vfs_exports.c and found that
> vfs_stdcheckexp is a VFS operation and not a vnode operation.
> 
> So for instance if one exports a mountpoint, and later changes his
> mind and export a directory under that mountpoint, clients that have
> mounted the mountpoint before the second operation will still have
> access.
> 
> Is this intentional (e.g. for performance consideration?)
> 
Short answer..yes.

Longer answer...
A vnode is only cached in the kernel, so the exports would drop out of
the cache when the vnode does. Also, this is checked for every RPC, so
it does need to be efficient and there is no easy way to determine of
the file object referred to by a vnode is a child (in the director subtree)
of another vnode with exports on it. (I suppose there might be a way to
hang exports off of every vnode, by having vnodes inherit their exports
from their parents, but that would be a major VFS/VOP change.)

Exporting a directory that is not a mount point only implements what
rwatson@ referred to as an "administrative control" enforced only by
mountd for the Mount protocol (NFS doesn't know anything about "mounts").
The ancient history of this goes something like:
- When Sun introduced NFS in 1985, the exports were only done by the
  Mount protocol and nothing was enforced by the kernel.
- I think I introduced the first case where exports were enforced on
  a per RPC case by hanging them off the mountpoints in the kernel, for
  4.3Reno (about 1988?).
  - When I did so, I felt that restricting /etc/exports to server mount
    points made sense (and I'll admit I still feel that way), but others
    wanted /etc/exports to remain SunOS compatible (since NFS was
    "their protocol" is those days).

It seems that changing the semantics of /etc/exports is very difficult
(it's a stumbling block w.r.t. adoption of nfse, as an example) at this
time so, although confusing, exporting a directory that is not a mount
point results in the entire mount point exported for NFS RPCs, but a
restriction of only mounting that directory is enforced for the Mount
protocol (only done at mount time and only for NFSv3).

rick

> Cheers,
> - --
> Xin LI <delphij@delphij.net> https://www.delphij.net/
> FreeBSD - The Power to Serve! Live free or die
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (FreeBSD)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBCAAGBQJQPTAfAAoJEG80Jeu8UPuzGykIAIBOrRNGsqgLNzIpEtqsBjKE
> ZSGTVLCfoAWeeOLKLuNv3yusFs1TVoIPWlr1Pnq/olQQWaShj7iFQioKQSQtMfJC
> xBJrn1IRGaYqR31VzxZ4KWof5QU+1hAgyxLnoZaHqYiNTIQWz2G0LYKs9QdQmyZ2
> IP5WXtGVXi6U1VClIpr6GzMebGMGObQqlpzqN23EEmUjIIML1lWX/3vNqXjp7WsH
> pcalf7PdthnKINn7IWcfLcmJydWQz4lihs/sm5oT9KwnlQtryH3pTa1C5qHP4vK2
> lIPc6jAhr9X0tY28YzBPRHej9ChVm61Qrkudeg7fGZ7arKFRDDG/h1TbJDEdCOw=
> =42qZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?140200696.1251333.1346245151029.JavaMail.root>