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 and/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 effective 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 parent directories, then subtracting all the restrictive information - so we know 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.
As an example, If FILE was actually C:\INETPUB\Sites\Realtors\JeffreyStokes.com\Images\Houses\SplitLevelRanch\Downtown\001.jpg on a Windows system, you would need to parse a total of ten separate ACLs (from the root of the C: drive all the way to the Downtown folder as well as 001.jpg itself) before you actually knew who could do what to 001.jpg.
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 using standard symbolic permissions:
-rwxr-x--- 1 STEVE GUYS 431 Mar 17 2003 FILE
This is the actual output of the ls command, with the -l flag. It tells us, among other things, that FILE is owned by the user STEVE and the group GUYS, and the permissions are rwx, rw-, and --- - meaning that STEVE can read, write, or execute FILE, the members of GUYS can read or execute FILE but not write to (or delete) it, and anyone else can't do anything at all with FILE. These three sets of permissions are known as "Owner/Group/World" permissions, and nothing can be inherited from anything else - what you see is what you get.
So which is better, ACLs or numeric permissions? It depends on who you ask, and what your needs are. Numeric permissions tend to lead to faster filesystems, as the overhead of checking ACLs, particularly ACLs with inheritable permissions, can sometimes add surprisingly dramatic amounts of overhead to simple file and directory manipulations. And even the apparent strength of ACLs - their obviously greater flexibility and granularity - can be their downfall; it is not at all uncommon for administrators of ACL'ed systems to be completely mistaken about the effective permissions on any given file because they forgot what it is inheriting from its parents, or didn't notice an allow or a deny explicitly set for one of several different groups which all have various conflicting privileges set on the same file.
As of the writing of this article, all versions of FreeBSD use numeric permissions models by default; however all versions of FreeBSD 5.x are capable of enabling ACLs using the tunefs command if so desired. As always, think carefully before enabling a new and far-reaching addition to your system - there are disadvantages and advantages to both models, and which model will be most appropriate is different for every system.
