On Thursday, August 1, 2013 5:45:29 PM UTC-5, Josh Cooper wrote:
On Thu, Aug 1, 2013 at 6:00 AM, jcbollinger <[email protected]
On Wednesday, July 31, 2013 8:22:01 AM UTC-5, [email protected]
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
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:
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
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.