nfs-utils/SOURCES/nfs-utils-2.3.3-exportfs-man-labels.patch
2021-09-09 22:48:30 +00:00

51 lines
1.7 KiB
Diff

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