Blob Blame History Raw
commit 7d5dcd2358df55353eed94a0e84b77bb3597634e
Author: J. Bruce Fields <bfields@redhat.com>
Date:   Fri Mar 27 13:11:28 2020 -0400

    exports man page: warn about subdirectory exports
    
    Subdirectory exports have a number of problems which have been poorly
    documented.
    
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

diff --git a/utils/exportfs/exports.man b/utils/exportfs/exports.man
index e3a16f6b..1d171849 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