From ca1eb318807f5b81279c9ca97a62cccf7a5ea4f2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nikola=20Forr=C3=B3?= <nforro@redhat.com>
Date: Mon, 20 Apr 2020 10:49:46 +0200
Subject: [PATCH] exports.5: warn about subdirectory exports

---
 nfs-utils/man5/exports.5 | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/nfs-utils/man5/exports.5 b/nfs-utils/man5/exports.5
index 4f95f3a..2ce46d9 100644
--- a/nfs-utils/man5/exports.5
+++ b/nfs-utils/man5/exports.5
@@ -492,6 +492,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 
-- 
2.26.0