From: Chip Salzenberg <chip@pobox.com>
To: nfs@lists.sourceforge.net
Subject: ACL patch - is this bad or good?
Date: Sat, 4 Dec 2004 17:26:59 -0500 [thread overview]
Message-ID: <20041204222659.GA5837@perlsupport.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 291 bytes --]
Hi there. A Debian user contributed a copy of what he says is a Red
Hat patch to support "acl" and "no_acl" options for NFS exports.
Is this patch OK?
--
Chip Salzenberg - a.k.a. - <chip@pobox.com>
People are supposed to die for freedom. Not the other way around.
[-- Attachment #2: nfs-utils-1.0.3-aclexport.patch --]
[-- Type: text/plain, Size: 3394 bytes --]
Add `no_acl' nfs export option
This patch adds the `acl' and `no_acl' nfs export options, which replace
the nfs_permission_mode module parameter of nfsd.o. The `no_acl' option
tells nfsd to mask off acl permissions so that clients will see a subset
of permissions that is safe even with old clients. Current clients
implement the NFSv3 ACCESS RPC, and therefore do not require the
`no_acl' export option. If no acls are supported in the nfs server, the
`no_acl' export option is not needed, either.
Thanks to Steve Dickson <SteveD@redhat.com> for proposing this.
Andreas Gruenbacher <agruen@suse.de>, SuSE Labs
Index: nfs-utils-1.0.4/utils/exportfs/exportfs.c
===================================================================
--- nfs-utils-1.0.4.orig/utils/exportfs/exportfs.c 2003-07-03 03:28:53.000000000 +0200
+++ nfs-utils-1.0.4/utils/exportfs/exportfs.c 2003-07-14 12:56:26.000000000 +0200
@@ -378,6 +378,8 @@ dump(int verbose)
c = dumpopt(c, "no_subtree_check");
if (ep->e_flags & NFSEXP_NOAUTHNLM)
c = dumpopt(c, "insecure_locks");
+ if (ep->e_flags & NFSEXP_NOACL)
+ c = dumpopt(c, "no_acl");
if (ep->e_flags & NFSEXP_FSID)
c = dumpopt(c, "fsid=%d", ep->e_fsid);
if (ep->e_mountpoint)
Index: nfs-utils-1.0.4/support/nfs/exports.c
===================================================================
--- nfs-utils-1.0.4.orig/support/nfs/exports.c 2003-05-30 07:17:56.000000000 +0200
+++ nfs-utils-1.0.4/support/nfs/exports.c 2003-07-14 12:56:26.000000000 +0200
@@ -185,6 +185,8 @@ putexportent(struct exportent *ep)
"no_" : "");
fprintf(fp, "%ssecure_locks,", (ep->e_flags & NFSEXP_NOAUTHNLM)?
"in" : "");
+ fprintf(fp, "%sacl,", (ep->e_flags & NFSEXP_NOACL)?
+ "no_" : "");
if (ep->e_flags & NFSEXP_FSID) {
fprintf(fp, "fsid=%d,", ep->e_fsid);
}
@@ -374,6 +376,10 @@ parseopts(char *cp, struct exportent *ep
ep->e_flags &= ~NFSEXP_NOAUTHNLM;
else if (strcmp(opt, "insecure_locks") == 0)
ep->e_flags |= NFSEXP_NOAUTHNLM;
+ else if (strcmp(opt, "acl") == 0)
+ ep->e_flags &= ~NFSEXP_NOACL;
+ else if (strcmp(opt, "no_acl") == 0)
+ ep->e_flags |= NFSEXP_NOACL;
else if (strncmp(opt, "mapping=", 8) == 0)
ep->e_maptype = parsemaptype(opt+8);
else if (strcmp(opt, "map_identity") == 0) /* old style */
Index: nfs-utils-1.0.4/utils/exportfs/exports.man
===================================================================
--- nfs-utils-1.0.4.orig/utils/exportfs/exports.man 2003-05-30 07:17:56.000000000 +0200
+++ nfs-utils-1.0.4/utils/exportfs/exports.man 2003-07-14 12:56:26.000000000 +0200
@@ -218,6 +218,21 @@ be explicitly requested with either of t
.IR auth_nlm ,
or
.IR secure_locks .
+.TP
+.IR no_acl
+This option tells nfsd to mask off acl permissions so that clients will
+only see a subset of the permissions on the exported file system. This
+subset is safe for NFSv2 clients, and for NFSv3 clients that perform
+access decisions locally. Current NFSv3 clients use the ACCESS RPC
+to perform all access decisions on the server. The
+.I no_acl
+option should be used for nfs exports with acl support that are exported
+to NFSv2 clients, or to NFSv3 clients that don't use the ACCESS RPC.
+This option is not needed for recent NFSv3 clients or if the exported
+file system has no acl support. The default is to export with acl
+support enabled (i.e.,
+.I no_acl
+is off.)
'''.TP
'''.I noaccess
next reply other threads:[~2004-12-04 22:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 22:26 Chip Salzenberg [this message]
2004-12-06 0:30 ` ACL patch - is this bad or good? Neil Brown
2004-12-06 19:24 ` Steve Dickson
2005-04-06 18:46 ` Chip Salzenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041204222659.GA5837@perlsupport.com \
--to=chip@pobox.com \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox