Client ACL tools

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
 
(2 intermediate revisions not shown)
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.
-
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 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 a huge 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.
+
Our patches make libacl dependent on ldap and a bunch of kerberos stuff.  Lots of core stuff (like "ls") depends in turn on libacl, so this is a pain.  One thing that would help would be to rip out the stuff that does gss name->local id mapping from libnfsidmap, and put that in gssd or someplace.  I'm not sure what else we should do.
-
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.
+
The code in general could use a little cleanup: style is inconsistent, parts could be made more simple and concise, etc.
-
 
+
-
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.
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.

Latest revision as of 22:36, 23 August 2010

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 a huge priority. Still, it might be helpful.

Our patches make libacl dependent on ldap and a bunch of kerberos stuff. Lots of core stuff (like "ls") depends in turn on libacl, so this is a pain. One thing that would help would be to rip out the stuff that does gss name->local id mapping from libnfsidmap, and put that in gssd or someplace. I'm not sure what else we should do.

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