Client ACL tools
From Linux NFS
| 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 | + | 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 NFSv4 acls the mapping produces (when translating from POSIX to NFSv4) are ugly and overly complicated. We need to fix that. Maybe this shouldn't be done right away, though, since it breaks backwards compatibility with servers that did the "strict" NFSv4->POSIX mapping. See [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-05.txt draft-ietf-nfsv4-acl-mapping-05.txt] or email bfields@umich.edu for details. | |
| - | + | 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. | ||
Revision as of 23:39, 15 December 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 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 NFSv4 acls the mapping produces (when translating from POSIX to NFSv4) are ugly and overly complicated. We need to fix that. Maybe this shouldn't be done right away, though, since it breaks backwards compatibility with servers that did the "strict" NFSv4->POSIX mapping. See draft-ietf-nfsv4-acl-mapping-05.txt or email bfields@umich.edu for details.
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.
