ACL

ACL - acronymic for Access Control List. Using the ACL model, any number of users and groups may have any number of different and/or overlapping permissions on a single file or directory. An NT style ACL, if you could view one directly and it was written in English, might look something like this:

Permissions for FILE:

owned by: [user STEVE]

user JOE: [read]
group GUYS: [read], [write]
group MEANIES: [disallow delete]
everyone: [no permissions]
Inherit parent permissions? [yes]

Interpreting this ACL properly can be tricky. What are JOE's effective permissions on this file? The short answer is, we have no idea! Why not? Well, first of all, we need to know whether JOE is a member of GUYS or MEANIES. Assuming that he is a member of GUYS and also of MEANIES, we now see that JOE has read and write permissions, but no delete permissions... or so we think. The catch is, this file has the "inherent parent permissions" flag set, so JOE might actually have anything from full permissions (except delete) to no permissions at all on this file, depending on what the parent - and possibly its parent, and so on ad infinitum - allows or specifically disallows! The net privilege level that JOE has on this file will actually be determined by first adding together all the permissive information from all the ACLs of FILE and its parents, then subtracting all the restrictive information - so we [i]know[/i] JOE won't be able to delete FILE, since we saw him specifically disallowed from doing so in FILE's own ACL, but we don't really know whether or not he is or is not allowed to do anything else to it without examining every ACL that could potentially bear.

Unixlike systems, including FreeBSD, generally use a more simplistic numeric permissions model, in which every file is owned by one User and one Group, and only three permission levels can be set: Owner, Group, and World. So let's examine FILE as it might be on a FreeBSD system:

-rw-r--r--  1 STEVE            GUYS                 431 Mar 17  2003 temp.sh