On 3/16/20 5:01 PM, J. Bruce Fields wrote: > From: "J. Bruce Fields" <bfields@xxxxxxxxxx> > > Subdirectory exports have a number of problems which have been poorly > documented. > > Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxx> Committed... (tag: nfs-utils-2-4-4-rc2) steved. > --- > utils/exportfs/exports.man | 27 +++++++++++++++++++++++++++ > 1 file changed, 27 insertions(+) > > diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man > index e3a16f6b276a..1d1718494e83 100644 > --- a/utils/exportfs/exports.man > +++ b/utils/exportfs/exports.man > @@ -494,6 +494,33 @@ export entry for > .B /home/joe > in the example section below, which maps all requests to uid 150 (which > is supposedly that of user joe). > + > +.SS Subdirectory Exports > + > +Normally you should only export only the root of a filesystem. The NFS > +server will also allow you to export a subdirectory of a filesystem, > +however, this has drawbacks: > + > +First, it may be possible for a malicious user to access files on the > +filesystem outside of the exported subdirectory, by guessing filehandles > +for those other files. The only way to prevent this is by using the > +.IR no_subtree_check > +option, which can cause other problems. > + > +Second, export options may not be enforced in the way that you would > +expect. For example, the > +.IR security_label > +option will not work on subdirectory exports, and if nested subdirectory > +exports change the > +.IR security_label > +or > +.IR sec= > +options, NFSv4 clients will normally see only the options on the parent > +export. Also, where security options differ, a malicious client may use > +filehandle-guessing attacks to access the files from one subdirectory > +using the options from another. > + > + > .SS Extra Export Tables > After reading > .I /etc/exports >
