[PATCH] Add `no_acl' nfs export option

[PATCH] Add `no_acl' nfs export option

[Andreas Gruenbacher]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

Hello,

The current kernel nfsd module has a `nfs_permission_mode' parameter, which 
can be used to force nfsd into masking acl permissions off on the server 
side. This is needed if the nfs server has acl support, but there are clients 
that are too old. There is some more documentation in the patch itself. 
Thanks to Steve for proposing this improvement, and for sending an initial 
patch.

Could this please be added to nfs-utils? Thanks.

Regards,
Andreas.

------------------------------------------------------------------
 Andreas Gruenbacher                     SuSE Labs, SuSE Linux AG
 mailto:agruen@suse.de                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany

[-- Attachment #2: export-acl.diff --]
[-- Type: text/x-diff, Size: 3947 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.3/support/include/nfs/export.h
===================================================================
--- nfs-utils-1.0.3.orig/support/include/nfs/export.h	2002-02-28 02:37:44.000000000 +0100
+++ nfs-utils-1.0.3/support/include/nfs/export.h	2003-07-08 16:14:26.000000000 +0200
@@ -24,6 +24,7 @@
 #define NFSEXP_NOSUBTREECHECK	0x0400
 #define NFSEXP_NOAUTHNLM	0x0800
 #define NFSEXP_FSID		0x2000
-#define NFSEXP_ALLFLAGS		0x3FFF
+#define NFSEXP_NOACL		0x4000
+#define NFSEXP_ALLFLAGS		0x7FFF
 
 #endif /* _NSF_EXPORT_H */
Index: nfs-utils-1.0.3/utils/exportfs/exportfs.c
===================================================================
--- nfs-utils-1.0.3.orig/utils/exportfs/exportfs.c	2002-10-11 17:39:55.000000000 +0200
+++ nfs-utils-1.0.3/utils/exportfs/exportfs.c	2003-07-08 16:14:26.000000000 +0200
@@ -347,6 +347,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_maptype == CLE_MAP_UGIDD)
Index: nfs-utils-1.0.3/support/nfs/exports.c
===================================================================
--- nfs-utils-1.0.3.orig/support/nfs/exports.c	2002-10-11 17:39:55.000000000 +0200
+++ nfs-utils-1.0.3/support/nfs/exports.c	2003-07-08 16:14:26.000000000 +0200
@@ -182,6 +182,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);
 	}
@@ -364,6 +366,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.3/utils/exportfs/exports.man
===================================================================
--- nfs-utils-1.0.3.orig/utils/exportfs/exports.man	2002-11-19 05:43:21.000000000 +0100
+++ nfs-utils-1.0.3/utils/exportfs/exports.man	2003-07-08 16:44:17.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

Re: [PATCH] Add `no_acl' nfs export option

[Andreas Gruenbacher]

[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]

Hello,

I noticed that the bit I wanted is already reserved in nfs-utils-1.0.4. Here 
is an updated nfs-utils patch. I am also attaching a patch against 
linux-2.6.0-test1.

Could someone please reserve the bit? Thanks.

Cheers,
Andreas.

On Tuesday 08 July 2003 16:55, Andreas Gruenbacher wrote:
> Hello,
>
> The current kernel nfsd module has a `nfs_permission_mode' parameter, which
> can be used to force nfsd into masking acl permissions off on the server
> side. This is needed if the nfs server has acl support, but there are
> clients that are too old. There is some more documentation in the patch
> itself. Thanks to Steve for proposing this improvement, and for sending an
> initial patch.
>
> Could this please be added to nfs-utils? Thanks.

------------------------------------------------------------------
 Andreas Gruenbacher                     SuSE Labs, SuSE Linux AG
 mailto:agruen@suse.de                     Deutschherrnstr. 15-19
 http://www.suse.de/                   D-90429 Nuernberg, Germany

[-- Attachment #2: export-acl.diff --]
[-- Type: text/x-diff, Size: 3928 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/support/include/nfs/export.h
===================================================================
--- nfs-utils-1.0.4.orig/support/include/nfs/export.h	2003-05-21 07:59:24.000000000 +0200
+++ nfs-utils-1.0.4/support/include/nfs/export.h	2003-07-14 12:57:07.000000000 +0200
@@ -25,6 +25,7 @@
 #define NFSEXP_NOAUTHNLM	0x0800
 #define NFSEXP_FSID		0x2000
 #define	NFSEXP_CROSSMNT		0x4000
-#define NFSEXP_ALLFLAGS		0x7FFF
+#define NFSEXP_NOACL		0x8000
+#define NFSEXP_ALLFLAGS		0xFFFF
 
 #endif /* _NSF_EXPORT_H */
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

[-- Attachment #3: nfsd-export-acl.diff --]
[-- Type: text/x-diff, Size: 572 bytes --]

Index: linux-2.6.0-test1/include/linux/nfsd/export.h
===================================================================
--- linux-2.6.0-test1.orig/include/linux/nfsd/export.h	2003-05-27 03:00:40.000000000 +0200
+++ linux-2.6.0-test1/include/linux/nfsd/export.h	2003-07-14 13:06:33.000000000 +0200
@@ -41,7 +41,8 @@
 #define NFSEXP_MSNFS		0x1000	/* do silly things that MS clients expect */
 #define NFSEXP_FSID		0x2000
 #define	NFSEXP_CROSSMNT		0x4000
-#define NFSEXP_ALLFLAGS		0x7FFF
+#define	NFSEXP_NOACL		0x8000
+#define NFSEXP_ALLFLAGS		0xFFFF
 
 
 #ifdef __KERNEL__

Re: [PATCH] Add `no_acl' nfs export option

[Neil Brown]

On Monday July 14, agruen@suse.de wrote:
> Hello,
> 
> I noticed that the bit I wanted is already reserved in nfs-utils-1.0.4. Here 
> is an updated nfs-utils patch. I am also attaching a patch against 
> linux-2.6.0-test1.
> 
> Could someone please reserve the bit? Thanks.

I'll definately reserve the bit, but I'm not very comfortable about
this concept.
My problem is that it doesn't seem clear how a sysadmin would decide
how to set this bit.  It is not clear, at least from the manpage
entry, exactly what the costs/benefits are of each setting, or how to
find out whether given clients need a particular setting.

Also, the manpage entry says in part:

>    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.

Surely the nfs server can detect itself if a filesystem supports ACLs,
and if a given request is arriving via NFSv2 or not, so it should be
able to assume "no_acl" in that case.

However this is actually a bit simplistic.  I think some NFSv2
clients, solaris in particular, does not depend on the mode but
performs zero-byte read and write requests to perform an equivalent
function to ACCESS.

Can you tell me concisely but precisely, possibly in the form of a
manpage entry,
  What is the cost of always using no_acl?
  What is the cost of never using no_acl?
  How do I determine which cost is greater in a given situation?

It would really like it if the option could be avoided altogether.
e.g. default to assume "no_acl" but switch to "acl" for a given client
for v3 access if an ACCESS request is seen, and for v2 access if a
zero byte READ or WRITE is seen.  Would that even come close to
working?

NeilBrown


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] Add `no_acl' nfs export option

[Andreas Gruenbacher]

On Tue, 2003-07-15 at 01:13, Neil Brown wrote:
> On Monday July 14, agruen@suse.de wrote:
> > Hello,
> > 
> > I noticed that the bit I wanted is already reserved in nfs-utils-1.0.4. Here 
> > is an updated nfs-utils patch. I am also attaching a patch against 
> > linux-2.6.0-test1.
> > 
> > Could someone please reserve the bit? Thanks.
> 
> I'll definately reserve the bit, but I'm not very comfortable about
> this concept.
> My problem is that it doesn't seem clear how a sysadmin would decide
> how to set this bit.  It is not clear, at least from the manpage
> entry, exactly what the costs/benefits are of each setting, or how to
> find out whether given clients need a particular setting.

You are right, this setting isn't particularly clear. The underlying
problem is the following (quoted from
http://acl.bestbits.at/problems.html).


> Version 2 of the NFS protocol (NFSv2) does not implement the ACCESS remote procedure call, and instead performs some access control decisions at the client machine based on the file mode permission bits. It grants the user access to cached files if it thinks access is granted be the file mode permission bits. This logic is no longer correct if access control lists are in effect; both false positives and denials might result.
> 
> Write access is not affected, as all writes are authenticated on the
> server in all cases. As a workaround to this problem the ACL patch
> adds the nfs_permission_mode parameter to the kernel NFS daemon. If
> nfs_permission_mode is set to 0 (the default setting), file mode
> permission bits are sent to clients unchanged. If nfs_permission_mode
> is set to 1, file mode permission bits are modified so that clients
> are never granted read access to files to which they do not have
> access on the server. See the acl(5) manual page for details.


> Also, the manpage entry says in part:
> 
> >    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.
> 
> Surely the nfs server can detect itself if a filesystem supports ACLs,
> and if a given request is arriving via NFSv2 or not, so it should be
> able to assume "no_acl" in that case.
> 
> However this is actually a bit simplistic.  I think some NFSv2
> clients, solaris in particular, does not depend on the mode but
> performs zero-byte read and write requests to perform an equivalent
> function to ACCESS.
> 
> Can you tell me concisely but precisely, possibly in the form of a
> manpage entry,
>   What is the cost of always using no_acl?
>   What is the cost of never using no_acl?
>   How do I determine which cost is greater in a given situation?
> 
> It would really like it if the option could be avoided altogether.
> e.g. default to assume "no_acl" but switch to "acl" for a given client
> for v3 access if an ACCESS request is seen, and for v2 access if a
> zero byte READ or WRITE is seen.  Would that even come close to
> working?
> 
> NeilBrown
> 

Re: [PATCH] Add `no_acl' nfs export option

[Andreas Gruenbacher]

Hello Neil,

(After switching mail clients I typed the wrong key and sent off the message
 accidentally before -- sorry.)

On Tue, 2003-07-15 at 01:13, Neil Brown wrote:
> On Monday July 14, agruen@suse.de wrote:
> > Hello,
> > 
> > I noticed that the bit I wanted is already reserved in nfs-utils-1.0.4. Here 
> > is an updated nfs-utils patch. I am also attaching a patch against 
> > linux-2.6.0-test1.
> > 
> > Could someone please reserve the bit? Thanks.
> 
> I'll definately reserve the bit, but I'm not very comfortable about
> this concept.
> My problem is that it doesn't seem clear how a sysadmin would decide
> how to set this bit.  It is not clear, at least from the manpage
> entry, exactly what the costs/benefits are of each setting, or how to
> find out whether given clients need a particular setting.

You are right, this setting isn't particularly clear. The underlying
problem is the following (parts quoted from
http://acl.bestbits.at/problems.html):

With POSIX ACLs, the group class file mode permission bits (i.e., the three
middle file mode permission bits) change their meaning. They no longer stand
for the owning group permissions, but for the mask ACL entry. The mask entry
defines the maximum permissions any user or group other than the owner or
others will have. The owning group may have fewer permissions than those that
are in the mask entry.

[] Version 2 of the NFS protocol (NFSv2) does not implement the ACCESS remote
[] procedure call, and instead performs some access control decisions at the
[] client machine based on the file mode permission bits. It grants the user
[] access to cached files if it thinks access is granted be the file mode
[] permission bits. This logic is no longer correct if access control lists
[] are in effect; both false positives and denials might result.

More precisely, NFSv2 clients and NFSv3 clients that don't use the ACCESS RPC
will wrongly grant access to file contents if all of the following is true:

 * The file contents are cached locally. (If they are not, the client will try
   to fetch them from the server, and will be denied access).
 * The user accessing the file is not the file owner, but is a member in the
   owning group.
 * The file has an extended ACL (i.e., its ACL differs from the base POSIX
   permissions).
 * The mask entry contains the requested permissions, but the owning group ACL
   entry does not contain all of those permissions.


False negatives will occur if all of this is true:

 * The file contents are cached locally.
 * The user accessing the file is not the file owner, and is not member in
   the owning group, but is a member in an additional ACL named user or
   named group ACL entry that would allow the access.
 * The other class file permission bits deny the access.


An even more bizarre case of fals epositives is this:

 * The file contents are cached locally.
 * The user accessing the file is not the file owner, and is not member in
   the owning group, but is a member in an additional ACL named user or
   named group ACL entry that would deny the access.
 * The other class file permission bits allow the access.


All those cases are sufficiently unlikely that they don't usually occur.
People who want to use ACLs are expected to upgrade their clients
as well. People who don't enable ACLs on their servers are unaffected.

Clients that are only used by a single user are unaffected: They will never cache
data to which this single user has no access.

[] Write access is not affected, as all writes are authenticated on the
[] server in all cases. As a workaround to this problem the ACL patch
[] adds [the `no_acl' export option] to the kernel nfs daemon. If
[] [`no_acl' is not specified] (the default setting), file mode
[] permission bits are sent to clients unchanged. If [`no_acl is specified],
[]  mode permission bits are modified so that clients
[] are never granted read access to files to which they do not have
[] access on the server.


> Also, the manpage entry says in part:
> 
> >    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.
> 
> Surely the nfs server can detect itself if a filesystem supports ACLs,
> and if a given request is arriving via NFSv2 or not, so it should be
> able to assume "no_acl" in that case.
> 
> However this is actually a bit simplistic.  I think some NFSv2
> clients, solaris in particular, does not depend on the mode but
> performs zero-byte read and write requests to perform an equivalent
> function to ACCESS.

Correct.

> Can you tell me concisely but precisely, possibly in the form of a
> manpage entry,
>   What is the cost of always using no_acl?

The no_acl option is implemented by retrieving and scanning the ACL of a file,
and by masking all permissions that could lead to false positives. This is done
for all NFS RPCs that return a file mode, so enabling this option is rather
expensive.

Apart from that, ACL aware clients ought to receive the file mode permission
bits unchanged instead of masked. For them, the masked permissions are actually
incorrect.

>   What is the cost of never using no_acl?

Without `no_acl', the above pathological situations can occur.

>   How do I determine which cost is greater in a given situation?


> It would really like it if the option could be avoided altogether.
> e.g. default to assume "no_acl" but switch to "acl" for a given client
> for v3 access if an ACCESS request is seen, and for v2 access if a
> zero byte READ or WRITE is seen.  Would that even come close to
> working?

It probably would, but strange effects would occur until the server learns who
is who. A list of known clients would have to be cached. Unless that list is
made persistent, the learning phase would reoccur after server crashes. While
the server doesn't know a client yet, the client would receive the wrong
permissions, which it might cache for several seconds. The client cache would
have to be secured against denial-of-service attacks (cache size).
All in all, auto-detection doesn't seem like a very good idea to me.


I will think about a better man page entry, and send you an improved version
tomorrow.


Cheers,
Andreas.