On Thursday, August 1, 2013 5:45:29 PM UTC-5, Josh Cooper wrote: > > Hi John, > > > On Thu, Aug 1, 2013 at 6:00 AM, jcbollinger > <john.bo...@stjude.org<javascript:> > > wrote: > >> >> >> On Wednesday, July 31, 2013 8:22:01 AM UTC-5, >> cha...@lyricalsoftware.comwrote: >>> >>> >>> Hopefully my $0.02 can we worth something here ;) I'd argue that it's >>> really a separate resource type - since the ACL is related to the user >>> space. If you're going to extend it to multiple providers (solaris as per >>> your example) it's really similar in idea to RBAC. In fact, if you look at >>> Windows ACLs, RBAC, and set/get facl you pretty much have a new type. Or >>> at least that's what I'd hope :) >>> >> >> >> And of course some Solaris is by no means the only Unix-y OS with ACL >> support. It is available on Linux, too, at least for the most frequently >> used filesystems, and I'm sure there are others. I'm inclined to agree >> that a type aimed at broad ACL / RBAC support would be a win. >> > > Yep, I agree. Now, how exactly to map the type across different > implementations? > > Windows ACLs support inheritance. An ACL can be marked as protected, > breaking inheritance, and for directories, everything below it. > > ACEs specify a subject (SID) and the rights that are granted/denied. This > is a bitfield, though users are more typically used to saying "Full > Control" or "Read & Execute". > > Windows ACEs can either be allow or deny, the order matters, and if no > ACEs match, access is denied. > > An ACE for a directory can be marked as object-inherit and/or > container-inherit. This doesn't affect the effective permissions on the > directory, only files and subdirectories, respectively. > > How are these similar & different to Unix-y ACLs? > >
Please allow me to refine my terminology from "Unix-y" to "POSIX". Here's a document that does a pretty good job of explaining POSIX ACLs: http://users.suse.com/~agruen/acl/linux-acls/online/. To answer your questions more directly, however: *ACL Inheritance*: POSIX defines "default" ACLs for directories, which provide the closest analog to Windows ACL inheritance. A directory's default ACL is assigned as the ACL of each file or directory created therein, and also as the default ACL of each directory created therein (subject to further restriction according to the requested initial mode for the file/directory). POSIX does not differentiate between files and directories in this regard, except inasmuch as only directories have default ACLs. ACLs are bound directly to each file and directory; they do not automatically change if their parent directory's default ACLs are changed, and access control decisions are based only on Files own ACLs (and I suspect this is true under the covers for Windows, too). POSIX differs from Windows in not defining features for automatically or implicitly updating the ACLs of a directory's contents when that directory's default ACL is modified: POSIX default ACLs are relevant only at the creation of new files and subdirectories. *ACL Scope and Structure*: POSIX ACEs reflect and extend the standard POSIX file permission scheme, allowing for read, write, and execute permission to be granted (or not) to specified users or groups. The traditional POSIX 'group' permissions map to a mask of the maximum permissions that any ACE other than the owner's or 'other' can grant. Access attempts that are not otherwise mapped to an ACE use the 'other' ACE that all files have; this is analogous to Windows's "Everyone". It does not necessarily grant any access. There is no affirmative permission denial as such, only absence of permission grant. It amounts to the same thing for users because if there is an ACE matching the UID of the process requesting access then that ACE determines access, or lack thereof. For groups, however, access can be granted through any of the process's groups, even if others of its groups do not have the requested access. POSIX ACL order is not significant, but ACE specificity is. When a user-specific ACE is applicable, it determines access, possibly in conjunction with the mask ACE. Otherwise, when one or more group-specific ACEs are applicable, they jointly determine access, together with any mask ACE. Only if no other ACE applies is the 'other' ACE relevant. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
