Client ACL tools

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
 
(3 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.
-
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 a huge 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).
+
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.
-
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.
+
The code in general could use a little cleanup: style is inconsistent, parts could be made more simple and concise, etc.
-
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.
+
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