Client ACL tools
From Linux NFS
| Line 3: | Line 3: | ||
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 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. | + | 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. See [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-05.txt draft-ietf-nfsv4-acl-mapping-05.txt] for details, or email bfields@umich.edu. |
| - | Second, the NFSv4 acls it produces (when translating from POSIX to NFSv4) are ugly and overly complicated. We need to | + | Second, the NFSv4 acls it 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. Again, see the draft above or email me for details. |
Third, 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. | ||
Revision as of 20:11, 10 October 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. See draft-ietf-nfsv4-acl-mapping-05.txt for details, or email bfields@umich.edu.
Second, the NFSv4 acls it 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. Again, see the draft above or email me 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.
