Client ACL tools

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
The libacl patches at http://linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-acl.git;a=summary have a few problems.
The libacl patches at http://linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-acl.git;a=summary have a few problems.
-
First, they implement acl-setting by querying the NFSv4 ACL, translating it to a posix ACL (throwing away anything not inherited or anything not effective, depending on whether we're modifying the effective or default ACL), modifying or replacing that as appropriate, then translating the result back into a NFSv4 ACL, and setting the result.
+
The correct solution to the problem they address may be to switch entirely to native NFSv4 acl tools, instead of using tools that translate between NFSv4 and POSIX acls (as do these tools) in order to provide a POSIX acl interface.  Also, it's unclear whether these patches are really going to get merged. So this stuff may not be ahuge priority.  Still, it might be helpful:
-
The problem is that in the process you throw out any inherited ACEs (if you're editing the default ACL), or any effective ACEs (if you're editing the effective ACL).  This is particularly noticeable if you use any command that adds or modifies a default ACL--you end up with *no* permissions to the directory in question, since you set an empty effective ACL (thus denying all access).
+
First, the NFSv4->POSIX mapping only accepts a very narrow range of NFSv4 ACLs.  We have algorithms which can do better (and have implemented them on the server side in the kernel), so this should be straightforward.  Email for details.
-
What the code *should* do is query the NFSv4 ACL, split it into purely inherited and purely effective parts (sometimes this requires duplicating aces--see the "split" function in fs/nfsd/nfs4acl.c in the kernel code), then replace only one of those two, leaving the other the same.
+
Second, the NFSv4 acls it produces (when translating from POSIX to NFSv4) are ugly and overly complicated.  We need to change.  Maybe this shouldn't be done right away, though, since it breaks backwards compatibility with servers that did the "strict" NFSv4->POSIX mapping. Again, email for details on the less complex mapping.
-
Second, the NFSv4->POSIX mapping only accepts a very narrow range of NFSv4 ACLs.  We have algorithms which can do better (and have implemented them on the server side in the kernel), so this should be straightforward.  Email for details.
+
Third, the code in general could use a little cleanup: style is inconsistent, parts could be made more simple and concise, etc.
 +
 
 +
And finally at some point we may want to actually submit this to Andreas or whoever's maintaining libacl, though this may be a hard sell.

Revision as of 18:19, 4 September 2006

The libacl patches at http://linux-nfs.org/cgi-bin/gitweb.cgi?p=bfields-acl.git;a=summary have a few problems.

The correct solution to the problem they address may be to switch entirely to native NFSv4 acl tools, instead of using tools that translate between NFSv4 and POSIX acls (as do these tools) in order to provide a POSIX acl interface. Also, it's unclear whether these patches are really going to get merged. So this stuff may not be ahuge priority. Still, it might be helpful:

First, the NFSv4->POSIX mapping only accepts a very narrow range of NFSv4 ACLs. We have algorithms which can do better (and have implemented them on the server side in the kernel), so this should be straightforward. Email for details.

Second, the NFSv4 acls it produces (when translating from POSIX to NFSv4) are ugly and overly complicated. We need to change. Maybe this shouldn't be done right away, though, since it breaks backwards compatibility with servers that did the "strict" NFSv4->POSIX mapping. Again, email for details on the less complex mapping.

Third, the code in general could use a little cleanup: style is inconsistent, parts could be made more simple and concise, etc.

And finally at some point we may want to actually submit this to Andreas or whoever's maintaining libacl, though this may be a hard sell.

Retrieved from "http://wiki.linux-nfs.org/wiki/index.php/Client_ACL_tools"
Personal tools