ACLs

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
m
(Others)
 
(14 intermediate revisions not shown)
Line 1: Line 1:
-
[http://wc1.worldcrossing.com/WebX/.1de60a09 viagra online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=207 real ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a0e cheap celexa] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=229 valium online] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=354 free nokia ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2866 cheap levitra] [http://news.engin.brown.edu/forums/thread-view.asp?tid=200 nokia ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=200 nexium online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=214 free cingular ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2910 free polyphonic ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2891 diethylpropion online] [http://students.hsc.unt.edu/housing/item.cfm?type=2885 tenuate online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=159 cheap cialis] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30366 free jazz ringtones] [http://wc1.worldcrossing.com/WebX/.1de609fa free online pharmacy] [http://wc1.worldcrossing.com/WebX/.1de60a22 but phentermine] [http://news.engin.brown.edu/forums/thread-view.asp?tid=208 free motorola ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1357 levitra online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=195 mono ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=199 cheap zyban] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=363 free samsung ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2901 free mp3 ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30235 cheap soma] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=136 cheap ultram] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=72 ambien online] [http://students.hsc.unt.edu/housing/item.cfm?type=2862 buy vicodin] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30258 cheap vicodin] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=182 free funny ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2890 zanaflex online] [http://wc1.worldcrossing.com/WebX/.1de609dc albuterol online] [http://wc1.worldcrossing.com/WebX/.1de60a20 nexium online] [http://students.hsc.unt.edu/housing/item.cfm?type=2875 propecia online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=165 but ambien] [http://wc1.worldcrossing.com/WebX/.1de609f8 free nokia ringtones] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=350 online alprazolam] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=139 viagra online] [http://students.hsc.unt.edu/housing/item.cfm?type=2874 cheap ultracet] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=91 cheap hoodia] [http://news.engin.brown.edu/forums/thread-view.asp?tid=175 cyclobenzaprine online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=201 free free ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=153 cheap phentermine] [http://students.hsc.unt.edu/housing/item.cfm?type=2848 soma online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30337 free real ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=94 free jazz ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a0a vicodin] [http://students.hsc.unt.edu/housing/item.cfm?type=2896 zyban online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=178 free ericsson ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a01 sagem ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1346 cheap diazepam] [http://news.engin.brown.edu/forums/thread-view.asp?tid=222 free sharp ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a1d free cingular ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30230 adipex] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=138 verizon ringtones] [http://wc1.worldcrossing.com/WebX/.1de609fe free qwest ringtones] [http://wc1.worldcrossing.com/WebX/.1de609e4 clonazepam online] [http://wc1.worldcrossing.com/WebX/.1de60a31 zanaflex online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=106 free mtv ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a1a mtv ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a15 free kyocera ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=218 sony ericsson ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=132 cheap tenuate] [http://students.hsc.unt.edu/housing/item.cfm?type=2904 free real ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=137 valium online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=168 paxil online] [http://library.cshl.edu/wp/vb/member.php?u=1367 didrex online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30295 sildenafil online] [http://wc1.worldcrossing.com/WebX/.1de609f7 nextel ringtones] [http://wc1.worldcrossing.com/WebX/.1de609f3 midi ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1348 ativan online] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=337 online xanax] [http://wc1.worldcrossing.com/WebX/.1de609e6 buy cyclobenzaprine] [http://library.cshl.edu/wp/vb/member.php?u=1360 order lorazepam] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=162 free alltel ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=176 cheap didrex] [http://news.engin.brown.edu/forums/thread-view.asp?tid=204 mp3 ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2911 free cingular ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a07 tracfone ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30241 xanax online] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=356 tracfone ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=111 order norco] [http://wc1.worldcrossing.com/WebX/.1de60a13 order fioricet] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=191 lorazepam online] [http://library.cshl.edu/wp/vb/member.php?u=1369 free ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2858 cheap viagra] [http://news.engin.brown.edu/forums/thread-view.asp?tid=224 free wwe ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2852 buy xanax] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30307 zoloft online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30331 free free ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a27 but sildenafil] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=145 xenical online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30339 free samsung ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30294 prozac online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=176 buy ultracet] [http://library.cshl.edu/wp/vb/member.php?u=1352 norco online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=189 but lipitor] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=362 free motorola ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=224 free sagem ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=101 meridia online] [http://wc1.worldcrossing.com/WebX/.1de609ee but hydrocodone] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30244 cheap diazepam] [http://wc1.worldcrossing.com/WebX/.1de609e0 cheap ativan] [http://students.hsc.unt.edu/housing/item.cfm?type=2861 norco online] [http://students.hsc.unt.edu/housing/item.cfm?type=2877 prozac online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=216 sonyericsson ringtones] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=360 free qwest ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=190 cheap lisinopril] [http://wc1.worldcrossing.com/WebX/.1de60a10 didrex online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=228 ultram online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=76 cialis online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30259 alprazolam online] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=359 nextel ringtones] [http://wc1.worldcrossing.com/WebX/.1de609e5 free cool ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2888 cheap lortab] [http://library.cshl.edu/wp/vb/member.php?u=1373 free nextel ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=216 cheap zyban] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=206 pharmacy online online] [http://library.cshl.edu/wp/vb/member.php?u=1344 cheap xanax] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=344 ativan] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30345 sprint ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30248 cheap ativan] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=131 sprint ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2871 wellbutrin online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=146 buy zanaflex] [http://news.engin.brown.edu/forums/thread-view.asp?tid=154 carisoprodol online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30280 propecia online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=118 buy prozac] [http://library.cshl.edu/wp/vb/member.php?u=1341 valium online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=144 cheap xanax] [http://students.hsc.unt.edu/housing/item.cfm?type=2905 motorola ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=112 but ortho] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=223 wellbutrin online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=169 levitra online] [http://news.engin.brown.edu/forums/thread-view.asp?tid=156 fioricet] [http://library.cshl.edu/wp/vb/member.php?u=1377 samsung ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30312 ortho online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30356 cool ringtones] [http://wc1.worldcrossing.com/WebX/.1de609f0 cheap lorazepam] [http://news.engin.brown.edu/forums/thread-view.asp?tid=187 cheap celexa] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30230 tramadol online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=211 polyphonic ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=214 zanaflex online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=110 nokia ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=189 ortho online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=237 samsung ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=151 soma online] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=99 cheap lorazepam] [http://students.hsc.unt.edu/housing/item.cfm?type=2912 sagem ringtones] [http://students.hsc.unt.edu/housing/item.cfm?type=2907 sprint ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a17 buy lipitor] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30334 free mp3 ringtones] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=234 free sprint ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=141 buy vigrx] [http://wc1.worldcrossing.com/WebX/.1de60a23 polyphonic ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a1f lisinopril online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=197 free mp3 ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1349 order viagra] [http://library.cshl.edu/wp/vb/member.php?u=1382 cingular ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30310 tenuate online] [http://students.hsc.unt.edu/housing/item.cfm?type=2922 free kyocera ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=206 free qwest ringtones] [http://wc1.worldcrossing.com/WebX/.1de609f9 cheap norco] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=351 buy clonazepam] [http://students.hsc.unt.edu/housing/item.cfm?type=2878 sildenafil online] [http://students.hsc.unt.edu/housing/item.cfm?type=2902 nextel ringtones] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=357 funny ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1347 cialis] [http://library.cshl.edu/wp/vb/member.php?u=1365 cheap ultracet] [http://news.engin.brown.edu/forums/thread-view.asp?tid=210 free sprint ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=158 cheap diazepam] [http://wc1.worldcrossing.com/WebX/.1de609ea free ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a25 samsung ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=88 free free ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1358 hydrocodone online] [http://library.cshl.edu/wp/vb/member.php?u=1339 order tramadol] [http://students.hsc.unt.edu/housing/item.cfm?type=2868 cheap ambien] [http://news.engin.brown.edu/forums/thread-view.asp?tid=228 free mtv ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=104 motorola ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=89 free funny ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=211 free music ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=80 free cool ringtones] [http://library.cshl.edu/wp/vb/member.php?u=1388 cheap fioricet] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=361 real ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=172 lorazepam] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=333 cheap soma] [http://news.engin.brown.edu/forums/thread-view.asp?tid=182 cheap clomid] [http://library.cshl.edu/wp/vb/member.php?u=1355 but clonazepam] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=205 order paxil] [http://news.engin.brown.edu/forums/thread-view.asp?tid=184 cheap lisinopril] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=124 samsung ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a04 free sonyericsson ringtones] [http://www.ees.ufl.edu/alumni/forums.asp?ForumId=5&TopicId=115 cheap phentermine] [http://library.cshl.edu/wp/vb/member.php?u=1387 alltel ringtones] [http://wc1.worldcrossing.com/WebX/.1de60a05 sprint ringtones] [http://news.engin.brown.edu/forums/thread-view.asp?tid=167 clonazepam online] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30283 buy didrex] [http://news.engin.brown.edu/forums/thread-view.asp?tid=157 ultram online] [http://itcweb.ecsu.edu/portal/forums.asp?ForumId=13&TopicId=230 verizon ringtones] [http://www.e.kth.se/cgi-bin/esekt/discussion?command=read&discussionid=4&id=30309 celexa online] [http://www.psfc.mit.edu/~jinseok/bbse/view.php?id=presentations&no=348 but norco] [http://wc1.worldcrossing.com/WebX/.1de60a11 diethylpropion online] = Introduction to NFSv4 ACLs =
+
= Introduction to NFSv4 ACLs =
-
Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a searate rpc program (instead of being part of the NFS protocol itself).
+
Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a separate rpc program (instead of being part of the NFS protocol itself).
The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows.  NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.
The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows.  NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.
Line 10: Line 10:
* [http://wt.xpilot.org/publications/posix.1e/download.html POSIX draft ACLs]: POSIX ACLs aren't really POSIX--they were never accepted--but some variation of them is implemented on many operating systems, including Linux.
* [http://wt.xpilot.org/publications/posix.1e/download.html POSIX draft ACLs]: POSIX ACLs aren't really POSIX--they were never accepted--but some variation of them is implemented on many operating systems, including Linux.
* The Linux man pages, specifically, acl(5), setfacl(1), getfacl(1), and setxattr(2).
* The Linux man pages, specifically, acl(5), setfacl(1), getfacl(1), and setxattr(2).
-
* The [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-03.txt POSIX<->NFSv4 mapping draft], which explains how we map between POSIX and NFSv4 ACLs.
+
* The [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-05.txt POSIX<->NFSv4 mapping draft], which explains how we map between POSIX and NFSv4 ACLs.
-
* The [http://www.citi.umich.edu/projects/nfsv4/ CITI NFSv4 project page], which has links to modified linux acl utilities with preliminary NFSv4 support
+
* The [http://www.citi.umich.edu/projects/nfsv4/ CITI NFSv4 project page], which has links to [http://www.citi.umich.edu/projects/nfsv4/linux/nfs4-acl-tools/ client tools for using NFSv4 ACLs] as well as [http://www.citi.umich.edu/projects/nfsv4/linux/acl-patches/ patches to libacl] which allow the client to treat NFSv4 ACLs as if they were POSIX ACLs.  Given the choice, we recommend the former approach, as the libacl patches are complex and affect basic utilities like "ls".
* [http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt draft-falkner-nfsv4-acls-00.txt], which suggests some clarifications to the NFSv4 ACL specification, and addresses some issues for NFSv4 implementors on UNIXy systems, including, for example, details on interactions with chmod.
* [http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt draft-falkner-nfsv4-acls-00.txt], which suggests some clarifications to the NFSv4 ACL specification, and addresses some issues for NFSv4 implementors on UNIXy systems, including, for example, details on interactions with chmod.
Line 18: Line 18:
== Server ==
== Server ==
-
None of the filesystems which the linux server exports support NFSv4 ACLs.  However, many of them do support POSIX ACLs.  So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem.  The mapping is imperfect, and prevents the server from accepting the full range of NFSv4 ACLs.  We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server.  However, this would prevent our ACLs from being enforced against local users of the same filesystem. The code to perform this mapping on the server side
+
None of the filesystems which the linux server exports support NFSv4 ACLs.  However, many of them do support POSIX ACLs.  So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem.  The mapping is imperfect.  It accepts most NFSv4 ACLs.  (The only exceptions are ACLs which explicitly deny permissions to read attributes or acls, or which explicitly deny the owner permissions to write attributes or acls.)  The lossy nature of the NFSv4->POSIX mapping means that querying an ACL will almost always result in an ACL returned that is different from the one setHowever, if the original ACL is representable as a POSIX ACL, then the ACL returned should represent equivalent permissions to the one set.  If not, then the ACL returned should have permissions that are stricter than those requested.
-
is in the kernel, in fs/nfsd/nfs4acl.c.
+
 
 +
The code to perform this mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.
 +
 
 +
We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server.  However, this would prevent our ACLs from being enforced against local users of the same filesystem.
 +
 
 +
Work is under way to include NFSv4 ACLs in the underlying filesystem, which would solve all of the above problems at the expense of increased filesystem complexity.  As of this writing, patches for production use are not yet available.
 +
 
 +
* The latest progress of Native NFSv4 ACLs on Linux [http://www.bestbits.at/richacl/ Richacls], and latest [https://getfedora.org/ Fedora] has included richacl package.
 +
* man-pages in package richacl [http://www.bestbits.at/richacl/man/richacl.7.txt richacl(7)] [http://www.bestbits.at/richacl/man/richaclex.7.txt richaclex(7)] [http://www.bestbits.at/richacl/man/getrichacl.1.txt getrichacl(1)] [http://www.bestbits.at/richacl/man/setrichacl.1.txt setrichacl(1)]
== Client ==
== Client ==
-
The client can also map between NFSv4 and POSIX ACLs, to allow it to support existing POSIX ACL interfaces.  However it does this mapping in userspace; the kernel deals only in NFSv4 ACLs, which it exposes through a special extended attribute ("system.nfs4_acl")Applications that use the POSIX ACL interfaces need to use a version of libacl that has been modified to do POSIX<->NFSv4 ACL mappingBut since userspace also has full access to the raw NFSv4 ACL, we can also provide utilities that get and set NFSv4 ACLs directly, without the need for mapping.
+
The kernel nfs client exposes ACLs on NFSv4 filesystems to userspace in the extended attribute named "system.nfs4_acl", which contains the raw xdr data which the client receives from the server as the value of the NFSv4 "acl" attributeWriting to that attribute will modify the ACL on the server.
 +
 
 +
We have [http://git.linux-nfs.org/?p=bfields/nfs4-acl-tools.git;a=summary client NFSv4 ACL tools]They present NFSv4 ACLs to the user untranslated, using NFSv4 names.  As a result they are usable against any NFSv4 server (even if the client doesn't know about all of the users on the server).
-
The data in the system.nfs4_acl attribute consists of the raw xdr data which the client receives from the server as the value of the "acl" attributeIt is up to userspace to do xdr decoding and encoding.
+
It is also possible to modify the client POSIX ACL tools to transparently map between POSIX and NFSv4 ACLs in userspace. This also requires mapping the names contained in the ACLs into local uid's.  We have [http://www.citi.umich.edu/projects/nfsv4/linux/acl-patches/ patches to libacl] available which do this.  However, this mapping is complex and (as on the server side) lossy.  Also, the mapping of names to id's is complicated, and (in our current implementation) introduces unfortunate dependencies of basic system tools (like ls) on a great deal of unrelated NFSv4 and krb5 codeFor these reasons we do not recommend this approach.
= The ACL Interoperability Problem =
= The ACL Interoperability Problem =
Line 61: Line 71:
* Windows does not have the special owner, group or everyone principals in ACEs.  You could handle owner and group ACEs by translating them to ACEs that refer explicitly to the current owner or group, but the result won't behave correctly under chown().
* Windows does not have the special owner, group or everyone principals in ACEs.  You could handle owner and group ACEs by translating them to ACEs that refer explicitly to the current owner or group, but the result won't behave correctly under chown().
-
* RFC3530 says that if an ACL neither allows nor denies a certain mode bit, then behavior is undefined.  But users of Windows ACLs expect them to deny by default.
+
* RFC3530 says that if an ACL neither allows nor denies a certain mode bit, then behavior is undefined.  But users of Windows ACLs expect them to deny by default. (I believe NFSv4 is now specified to have Windows behavior in RFC3530bis and RFC5661?)
* Windows documentation suggests that if some but not all requested access bits have been allowed, then DENY aces will still apply even if they only deny bits among those already allowed.  This has the somewhat bizarre result that an ACL can allow certain permissions individually but deny them in combination.  The NFSv4 ACL algorithm doesn't have this property.  (We're waiting the results of experiments to confirm this property of Windows ACLs.)
* Windows documentation suggests that if some but not all requested access bits have been allowed, then DENY aces will still apply even if they only deny bits among those already allowed.  This has the somewhat bizarre result that an ACL can allow certain permissions individually but deny them in combination.  The NFSv4 ACL algorithm doesn't have this property.  (We're waiting the results of experiments to confirm this property of Windows ACLs.)
Line 68: Line 78:
The [http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html new OSX ACLs] seem to be essentially identical to Windows ACLs; the obvious major exception being that instead of denying by default, when the ACL doesn't determine access, OSX falls back on the mode bits.
The [http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html new OSX ACLs] seem to be essentially identical to Windows ACLs; the obvious major exception being that instead of denying by default, when the ACL doesn't determine access, OSX falls back on the mode bits.
-
Though there is at least one [http://sourceforge.net/projects/ngacl proof of concept NFSv4/Windows ACL implementation for Linux], we know of no concerted effort to push native Linux support for NFSv4/Windows ACLs.  However, Solaris and AIX both seem to be adding support for NFSv4 ACLs.  Two Sun developers have an internet draft [http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt draft-falkner-nfsv4-acls-00.txt] which proposes more precise semantics for NFSv4 ACLs and deals with mode-bit mapping and other issues of particular interest for NFSv4 ACL implementors on POSIX systems.
+
Though there is at least one [http://sourceforge.net/projects/ngacl proof of concept NFSv4/Windows ACL implementation for Linux], we know of no concerted effort to push native Linux support for NFSv4/Windows ACLs.  However, AIX, [http://wiki.freebsd.org/NFSv4_ACLs FreeBSD], and Solaris support NFSv4 ACLs.  Two Sun developers have an internet draft [http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt draft-falkner-nfsv4-acls-00.txt] which proposes more precise semantics for NFSv4 ACLs and deals with mode-bit mapping and other issues of particular interest for NFSv4 ACL implementors on POSIX systems; implementation in ZFS (in both Solaris and FreeBSD) and UFS (FreeBSD) implement semantics described in this draft.
In practice many Windows applications (such as Explorer) may use only a small subset of Windows ACLs, and may not deal well with ACLs outside of that subset; for example, they generally want to sort all DENY ACE's before ALLOW ACE's.  See
In practice many Windows applications (such as Explorer) may use only a small subset of Windows ACLs, and may not deal well with ACLs outside of that subset; for example, they generally want to sort all DENY ACE's before ALLOW ACE's.  See
Line 88: Line 98:
=== Others ===
=== Others ===
-
[http://www.openafs.org/pages/doc/UserGuide/auusg007.htm AFS ACLs] are only set on directories, and affect the directory and all files contained in it; hardlinks are unsupported.  They have more access bits than POSIX ACLs, but less than NFSv4/Windows ACLs.  Denies are supported (though discouraged), and always supercede allows.  (So an AFS ACL is roughly equivalent to a Windows/NFSv4 ACL with all DENY aces at the beginning.)
+
[https://docs.openafs.org/UserGuide/HDRWQ46.html AFS ACLs] are only set on directories, and affect the directory and all files contained in it; hardlinks are unsupported.  They have more access bits than POSIX ACLs, but less than NFSv4/Windows ACLs.  Denies are supported (though discouraged), and always supercede allows.  (So an AFS ACL is roughly equivalent to a Windows/NFSv4 ACL with all DENY aces at the beginning.)
[http://www.csupomona.edu/reference/dfs3.1/html/AdminGd/duagd008.htm#HDRWQ97 DCE ACLs] appear to be a superset of POSIX ACLs, with additional mode bits and entities.
[http://www.csupomona.edu/reference/dfs3.1/html/AdminGd/duagd008.htm#HDRWQ97 DCE ACLs] appear to be a superset of POSIX ACLs, with additional mode bits and entities.
AIX?  Others?
AIX?  Others?
-
 
-
AFS ACLs may be a particular issue here at CITI since we have AFS volumes that we'll want to transfer to NFSv4 at some point.  But fortunately that will probably only require a one-time translation; we're not going to try to provide simultaneous NFSv4 and AFS acess....
 
== Interoperability Strategies ==
== Interoperability Strategies ==
Line 106: Line 114:
This approach has a few disadvantages:
This approach has a few disadvantages:
-
* The NFSv4 ACLs produced by this mapping are hard to read, and are impossible for users to manipulate without software that understands the mapping to aid them.  Thus a user modifying the ACLs through an application that doesn't treat them as POSIX ACLs will almost certainly produce an ACL that can no longer be read by applications that expect POSIX ACLs.
+
* The NFSv4 ACLs produced by this mapping are hard to read, and are nearly impossible for users to manipulate without software that understands the mapping to aid them.  Thus a user modifying the ACLs through an application that doesn't treat them as POSIX ACLs will almost certainly produce an ACL that can no longer be read by applications that expect POSIX ACLs.
* An NFSv4 server like Linux with backend POSIX ACLs can accept only a very limited subset of ACLs, probably impossible to generate without software that understands the mapping.
* An NFSv4 server like Linux with backend POSIX ACLs can accept only a very limited subset of ACLs, probably impossible to generate without software that understands the mapping.
-
Strict mapping between Windows and NFSv4 ACLs is much easier; probably all that's necessary is the addition or subtraction of a "DENY EVERYONE@" ACE at the end of each ACL.  This might also cause problems, though.
+
Strict mapping between Windows and NFSv4 ACLs is much easier.
=== Lossy mapping ===
=== Lossy mapping ===
Line 116: Line 124:
(Summarize tradeoffs.)
(Summarize tradeoffs.)
 +
 +
The current Linux server also implements a lossy algorithm described in [http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-05.txt draft-ietf-nfsv4-acl-mapping-05.txt].
POSIX ACLs provide another interesting example: mode bits are themselves a primitive sort of ACL, and operating systems that support POSIX ACLs have to continue supporting mode bits as well.  They do this in a rather interesting way--the POSIX ACL is guaranteed not to give more access than the corresponding mode bits, except that some named users and groups may be permitted more access than they otherwise would, with the restriction that that additional access is bounded by the mode bits given to the file's group.
POSIX ACLs provide another interesting example: mode bits are themselves a primitive sort of ACL, and operating systems that support POSIX ACLs have to continue supporting mode bits as well.  They do this in a rather interesting way--the POSIX ACL is guaranteed not to give more access than the corresponding mode bits, except that some named users and groups may be permitted more access than they otherwise would, with the restriction that that additional access is bounded by the mode bits given to the file's group.

Latest revision as of 15:57, 10 July 2020

Contents

Introduction to NFSv4 ACLs

Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a separate rpc program (instead of being part of the NFS protocol itself).

The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows. NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.

Useful references:

  • rfc3530 (especially section 5.11)]
  • POSIX draft ACLs: POSIX ACLs aren't really POSIX--they were never accepted--but some variation of them is implemented on many operating systems, including Linux.
  • The Linux man pages, specifically, acl(5), setfacl(1), getfacl(1), and setxattr(2).
  • The POSIX<->NFSv4 mapping draft, which explains how we map between POSIX and NFSv4 ACLs.
  • The CITI NFSv4 project page, which has links to client tools for using NFSv4 ACLs as well as patches to libacl which allow the client to treat NFSv4 ACLs as if they were POSIX ACLs. Given the choice, we recommend the former approach, as the libacl patches are complex and affect basic utilities like "ls".
  • draft-falkner-nfsv4-acls-00.txt, which suggests some clarifications to the NFSv4 ACL specification, and addresses some issues for NFSv4 implementors on UNIXy systems, including, for example, details on interactions with chmod.

Design of the linux NFSv4 ACL implementation

Server

None of the filesystems which the linux server exports support NFSv4 ACLs. However, many of them do support POSIX ACLs. So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem. The mapping is imperfect. It accepts most NFSv4 ACLs. (The only exceptions are ACLs which explicitly deny permissions to read attributes or acls, or which explicitly deny the owner permissions to write attributes or acls.) The lossy nature of the NFSv4->POSIX mapping means that querying an ACL will almost always result in an ACL returned that is different from the one set. However, if the original ACL is representable as a POSIX ACL, then the ACL returned should represent equivalent permissions to the one set. If not, then the ACL returned should have permissions that are stricter than those requested.

The code to perform this mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.

We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server. However, this would prevent our ACLs from being enforced against local users of the same filesystem.

Work is under way to include NFSv4 ACLs in the underlying filesystem, which would solve all of the above problems at the expense of increased filesystem complexity. As of this writing, patches for production use are not yet available.

Client

The kernel nfs client exposes ACLs on NFSv4 filesystems to userspace in the extended attribute named "system.nfs4_acl", which contains the raw xdr data which the client receives from the server as the value of the NFSv4 "acl" attribute. Writing to that attribute will modify the ACL on the server.

We have client NFSv4 ACL tools. They present NFSv4 ACLs to the user untranslated, using NFSv4 names. As a result they are usable against any NFSv4 server (even if the client doesn't know about all of the users on the server).

It is also possible to modify the client POSIX ACL tools to transparently map between POSIX and NFSv4 ACLs in userspace. This also requires mapping the names contained in the ACLs into local uid's. We have patches to libacl available which do this. However, this mapping is complex and (as on the server side) lossy. Also, the mapping of names to id's is complicated, and (in our current implementation) introduces unfortunate dependencies of basic system tools (like ls) on a great deal of unrelated NFSv4 and krb5 code. For these reasons we do not recommend this approach.

The ACL Interoperability Problem

We now have three ACL models to deal with: NFSv4, Windows, and "POSIX ACLs"/mode bits. And we have to decide what to do with them all in the face of existing users, tools, and system interfaces that assume one or the other.

More specifically:

A server has to store ACL's persistently on its filesystem. There are immense advantages to storing those ACL's using whatever ACL's the filesystem and operating system support, because that will ensure that they are automatically enforced against other applications and protocol services using the same filesystem.

Some servers are therefore translating to and from their native format. Others are implementing NFSv4 ACL's in the filesystem.

The client in theory has a simpler problem--it can always provide its own application for manipulating NFSv4 ACLs. However:

  • Some applications manipulate ACL's directly using interfaces designed for one particular ACL model (e.g. MS Office apparently does this on temporary files--other examples?)
  • Users may have experience with existing ACL models and tools, which may be better integrated into standard file managers
  • Administrators may have built up scripts that manipulate or check ACL's.

For these reasons client implementers may also want to support preexisting ACL models.

Since individual clients and applications with different ACL models may not deal well with the full generality of NFSv4 ACLs, problems may also arise from clients reading and modifying ACLs written by clients with different expectations.

ACL models

NFSv4 and Windows ACLs

NFSv4 ACLs are documented by section 5.11 of rfc3530. See msdn for Windows ACL documentation.

The two ACL models are essentially the same, with some minor differences:

  • Windows does not have the special owner, group or everyone principals in ACEs. You could handle owner and group ACEs by translating them to ACEs that refer explicitly to the current owner or group, but the result won't behave correctly under chown().
  • RFC3530 says that if an ACL neither allows nor denies a certain mode bit, then behavior is undefined. But users of Windows ACLs expect them to deny by default. (I believe NFSv4 is now specified to have Windows behavior in RFC3530bis and RFC5661?)
  • Windows documentation suggests that if some but not all requested access bits have been allowed, then DENY aces will still apply even if they only deny bits among those already allowed. This has the somewhat bizarre result that an ACL can allow certain permissions individually but deny them in combination. The NFSv4 ACL algorithm doesn't have this property. (We're waiting the results of experiments to confirm this property of Windows ACLs.)

A bigger (and perhaps more important!) difference is in the way ACEs refer to users--NFSv4 uses string names of the form user@domain, Windows uses SIDs--but we're ignoring the name-mapping issue for now.

The new OSX ACLs seem to be essentially identical to Windows ACLs; the obvious major exception being that instead of denying by default, when the ACL doesn't determine access, OSX falls back on the mode bits.

Though there is at least one proof of concept NFSv4/Windows ACL implementation for Linux, we know of no concerted effort to push native Linux support for NFSv4/Windows ACLs. However, AIX, FreeBSD, and Solaris support NFSv4 ACLs. Two Sun developers have an internet draft draft-falkner-nfsv4-acls-00.txt which proposes more precise semantics for NFSv4 ACLs and deals with mode-bit mapping and other issues of particular interest for NFSv4 ACL implementors on POSIX systems; implementation in ZFS (in both Solaris and FreeBSD) and UFS (FreeBSD) implement semantics described in this draft.

In practice many Windows applications (such as Explorer) may use only a small subset of Windows ACLs, and may not deal well with ACLs outside of that subset; for example, they generally want to sort all DENY ACE's before ALLOW ACE's. See this msdn documentation.

Documentation of existing Windows ACL manipulation tools would also be useful; cacls.exe has been mentioned as one tool that is commonly used by administrators and whose interface might be worth examination by people implementing NFSv4 ACL tools.

POSIX ACLs

As noted above, these aren't really POSIX, though they've been implemented on lots of operating systems, including Solaris and Linux. See the POSIX draft for detailed documentation.

NFSv4/Windows ACLs are more fine-grained than POSIX ACLs.

The popularity and flexibility of Windows/NFSv4 ACLs makes it tempting to just ignore POSIX ACLs. However,

  • The flexibility of Windows ACL's could make them harder to use them correctly. People with experience suggested that in practice users do have trouble. (Any references to published evidence here would be useful. Windows Access Control Demystified studies ACL misconfiguration problems, though the specific problems identified seem to be with access bits not relevant to file system permissions.)
  • POSIX ACL's are what are currently available on Linux and some other platforms, so we can expect that they are what developers are currently coding to; thus even if they aren't widely used now, they may be in a few years (by which time file managers have built-in support for them, etc.; see this news about Nautilus POSIX ACL support.

Others

AFS ACLs are only set on directories, and affect the directory and all files contained in it; hardlinks are unsupported. They have more access bits than POSIX ACLs, but less than NFSv4/Windows ACLs. Denies are supported (though discouraged), and always supercede allows. (So an AFS ACL is roughly equivalent to a Windows/NFSv4 ACL with all DENY aces at the beginning.)

DCE ACLs appear to be a superset of POSIX ACLs, with additional mode bits and entities.

AIX? Others?

Interoperability Strategies

In the following we tend to focus on mapping between different ACL types, though of course that's only one tool.

Strict Mapping

The POSIX<->NFSv4 mapping draft), which is what the linux client and server implement, takes a very strict approach: POSIX ACLs are mapped on the fly to NFSv4 ACLs, but attempts to get or set NFSv4 ACLs fail unless they are precisely equal to a POSIX-mapped NFSv4 ACL. Since NFSv4 ACLs are much finer-grained, almost all NFSv4 ACLs will fail to map to a POSIX ACL.

This approach has a few disadvantages:

  • The NFSv4 ACLs produced by this mapping are hard to read, and are nearly impossible for users to manipulate without software that understands the mapping to aid them. Thus a user modifying the ACLs through an application that doesn't treat them as POSIX ACLs will almost certainly produce an ACL that can no longer be read by applications that expect POSIX ACLs.
  • An NFSv4 server like Linux with backend POSIX ACLs can accept only a very limited subset of ACLs, probably impossible to generate without software that understands the mapping.

Strict mapping between Windows and NFSv4 ACLs is much easier.

Lossy mapping

See Jeremy Allison's presentation for a description of a mapping used to store and retrieve NFSv4 ACLs from a backend that supports only POSIX ACLs. This mapping always succeeds, sacrificing some semantics instead.

(Summarize tradeoffs.)

The current Linux server also implements a lossy algorithm described in draft-ietf-nfsv4-acl-mapping-05.txt.

POSIX ACLs provide another interesting example: mode bits are themselves a primitive sort of ACL, and operating systems that support POSIX ACLs have to continue supporting mode bits as well. They do this in a rather interesting way--the POSIX ACL is guaranteed not to give more access than the corresponding mode bits, except that some named users and groups may be permitted more access than they otherwise would, with the restriction that that additional access is bounded by the mode bits given to the file's group.

When modifying mode bits, to ensure that chmod restricts access, without completely removing an existing POSIX ACL, POSIX has a special MASK ACE that restricts the access that may be given by named user and group ACEs without requiring those ACEs be modified or removed.

Also, standard commands such as "ls" are modified to provide some visual indication that a POSIX ACL is present even when only the mode bits are displayed.

The Windows Services for Unix documentation provides another interesting example: they provide an NFS server that must use a Windows backend to store mode bits. (They don't appear to deal with POSIX ACLs.) Their mapping from mode bits to Windows ACLs is similar to the mapping described by the POSIX<->NFSv4 ietf draft, though they leave out some superfluous DENY aces. The mapping back from Windows ACLs to mode bits necessarily loses some information, but never fails.

Other options

A server could store multiple ACL's and enforce only one type, or enforce all of them (permitting access only if each ACL permits access). Setting one type of ACL could remove the others, or replace them by translations of the ACL set, or (gack) not affect the other ACLs at all.

User tools need to fail gracefully when mapping fails; e.g. they should be able to give the user a helpful error message and give them the option of overwriting the ACL completely or leaving it alone.

Personal tools