Confused about ACLs

ACL's and Unix (POSIX) permissions are two different things.

Basically OS X uses the POSIX permission system with only 3 rights (r w x) and 3 category's (owner-group-everyone)

For the system EVERYTHING IS A FILE and all access to a file depends on the rights a user (applications are also only a kind of "users") of the system have on a file. Folders are also just files from the systems view.

For that there are no USER RIGHTS on a system. User rights are only a wording to make it for people understandable what one may do or not.

All rights a user may have bases only on the rights either to read, write or execute a file depending on his relation to the file as Owner, Member of a Group or being Everyone.

That works well on a isolated system with users are organized in groups.

If a filesystem became accessible from outside the system (e.g. over a network) you run quickly into the limitations of that concept.

Using only the POSIX permissions will have the consequences that every user who will have granted access to the filesystem must have a unique account on the system for making it possible to check if the user is the owner of a file, member of a group or everyone (nobody).

On that point the ACL's became usefull, as users wanting to have a right to access a file not longer must have a system account.

ACL's are a supplement to the existing POSIX permissions, so you don't necessarily need to use ACL's. The conventional rules for access rights still apply, but some optional new rules can be added.

You can see a ACL as a list of individual rights which can be attached to a file system object.

For that the ACL can either be empty -in this case, only the conventional POSIX permissions apply-, or it can contain one or more objects called Access Control Entries.

An Access Control Entry includes the following information:

• to which users does this entry apply (individual user or a user group)?
• does this entry allow or deny access? (deny rules out allow)
• which right in particular is allowed or denied, respectively?
• how should this entry be inherited from a folder to the contents of this folder?

ACL's allow the definition of 13 different rights to access a file-system object, so you can give a very fine tune on what one may do or not.

ok so fare?

Cheers - Lupunus

axelessbaum wrote:

Ok, that makes sense.

But when you DO have users who access the files over a network, and the ACLs apply, how do those users get any information about the ACLs? How do they know what folders they can and cannot write into?

I think you mix up a bit different things.

So lets try to sort out without diving to deep into technical details.

First computers work only with numbers not with names. Names (user- or filenames) have only two purposes: Give the user some convenience and (user name) for login authentication.

As wrote before, for the system "everything is a file" and every object (file) on the system (filesystem) have to belong to someone regardless of being a "human" equivalent or a system-user (daemon)

Therefore a object (file) that belongs to no one is called a "orphan" and have to be prevented or fixed by permission repair or filesystem check.

A USER is, from the view of a unixoide system (like OS X is), a number "UID" (UserID) in a list among others. Take a look in /etc/passwd where all system users are listed.

Human "users" may be listed elsewhere depending on the authentication method used.

Some of the "users" have the privilege to login to system either directly or from remote.

All other humans or machines looking at the system or the filesystem are "Others" (everyone) from the systems point of view.

They have only the rights to look onto or access objects (files) as defined in the Others (Everyone) section of a object rights table. Mostly just -r- or no rights at all.

Your example:

Given, that you have created some human "users" on the OS X Server with the (default) privilege to log in.

If such a user accesses the system either from console (directly) or from remote, the user have to login for using his rights on the filesystem e.g. to access, manipulate or delete objects the user have the rights on.

For such a "logged in" user the POSIX permission system apply's.

If you set up an additional server application (Share) to grant others access to a defined set of objects (volume/folder) a user connecting from remote with the correct protocol become a client of this server application. (e.g. a Samba (SMB) Server running on your system)

If there is a authentication for this user available "name-password" the user become a server share user with predefined rights on that share.

Mostly (and that may leads to confusion) the used login name / password sheme is the same as on the system. But you have to see that names are useless for the system. The system intern use only the UID's. Names are only valid for the authentication (login) process to compare name and password to the entry in the authentication database.

But, and this is the point, this construction is like a system (server) inside a system (server) and has not much to do with the underlying system (e.g. OS X server) except the underlying system (OS X Server) granted the "system-user" Share-server to use its resources (filesystem).

For such a server-user a different set of permissions can be defined and stored maybe in a ACL.

So if the Share-Server-User "Greta" looks on the Share, she see the rights on "her" files as defined in the ACL and that a file belongs to "Greta"

A logged in OS X system user looking on the same file will see the POSIX sheme as the underlying filesystem definitely is owned by Admin who is a member of the group Staff and the permissions are set for Admin-Staff-Everyone.

Same with the VNC (as you wrote).

To VNC on a system, first on that system a VNC Server must running and you did not log in as Admin of the OS X Server but as a user named Admin on the VNC Server. For convenience the VNC uses the authentication system of the server but the file permissions on the Share-Server you will see are the ACL's not the POSIX ones as "you" look thru the VNC-Server on files of the Share-Server. (where the VNC is no valid user) ........

Dont let's dive go to deep in technical functions 🙂

Got it?

Cheers - Lupunus

axelessbaum wrote:

Ok, that makes sense.

But when you DO have users who access the files over a network, and the ACLs apply, how do those users get any information about the ACLs? How do they know what folders they can and cannot write into?

The users don't need to know, this is all managed by the server or operating system. In the case of accessing a server shared volume, when the user tries accessing a file or folder they make a request which is process by the server. The server compares their user account to the ACL lists to see what if any permissions the user is allowed and then allows the user to perform their task if they have the right permission, e.g. reading a file, or writing to a file, or deleting a file.

ACLs as Lupunus said give far more precise control than the limited POSIX approach.

What I would say that Lupunus did not is that my own experience is that with Snow Leopard or Lion servers it is almost compulsory to use ACLs rather than POSIX permissions.

I would also make it clear that one can use ACLs locally on a computer, they are defined and work exactly the same way but the operating system locally checks to see if a user has the level of access needed to do an operation.

Apple were a little late in implementig ACLs, both Linux and Windows had them before they got added to Mac OS X.