summaryrefslogtreecommitdiff
path: root/fs/nfsd/export.c
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@redhat.com>2017-01-03 12:30:11 -0500
committerJ. Bruce Fields <bfields@redhat.com>2017-01-31 12:31:54 -0500
commit32ddd944a056c786f6acdd95ed29e994adc613a2 (patch)
treede1987f57f81d68f1ef68d89297d262abf43f37a /fs/nfsd/export.c
parent5cf23dbb1d3122bbc378dbbd96880a086c1b63df (diff)
nfsd: opt in to labeled nfs per export
Currently turning on NFSv4.2 results in 4.2 clients suddenly seeing the individual file labels as they're set on the server. This is not what they've previously seen, and not appropriate in may cases. (In particular, if clients have heterogenous security policies then one client's labels may not even make sense to another.) Labeled NFS should be opted in only in those cases when the administrator knows it makes sense. It's helpful to be able to turn 4.2 on by default, and otherwise the protocol upgrade seems free of regressions. So, default labeled NFS to off and provide an export flag to reenable it. Users wanting labeled NFS support on an export will henceforth need to: - make sure 4.2 support is enabled on client and server (as before), and - upgrade the server nfs-utils to a version supporting the new "security_label" export flag. - set that "security_label" flag on the export. This is commit may be seen as a regression to anyone currently depending on security labels. We believe those cases are currently rare. Reported-by: tibbs@math.uh.edu Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'fs/nfsd/export.c')
-rw-r--r--fs/nfsd/export.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 43e109cc0ccc..e71f11b1a180 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -1102,6 +1102,7 @@ static struct flags {
{ NFSEXP_NOAUTHNLM, {"insecure_locks", ""}},
{ NFSEXP_V4ROOT, {"v4root", ""}},
{ NFSEXP_PNFS, {"pnfs", ""}},
+ { NFSEXP_SECURITY_LABEL, {"security_label", ""}},
{ 0, {"", ""}}
};