Apple's Unix Access Control Systems

Simple and elegant.

Get It Try It

It must be bewildering coming from the world of Windows or the topography of tap-tap, but files on a Unix system, where users have adequate control, offer a lot of possibilities for greater granularity - and a lot of potential potholes for screwing up. Not all is 'alpine/dottie', and it's certainly not like the world of Bill Gates either. Understanding what access controls are at your disposal (and potentially can trip you up) takes a bit of time to learn.

Hopefully this quick tutorial can get you on the right path.

There are several types of 'access control' on a Unix system like Apple's, but, before we begin, let's look closer at what's meant by 'access control'.

Access control in the old days, of the standalone personal machine: that was the lock on the door where the computer was kept. Once you got through that door, you needed only turn the machine on, and all was at your disposal, without restriction.

Microsoft Windows works a lot like that even today, which is one of the reasons that platform is plagued with viruses and other exotic strains of malware meant to do you harm.

Access control today takes on two possible forms; discretionary access control and mandatory access control.

Discretionary access control: when access control is optional. When you the user can decide whether access to something in your system should be limited or controlled.

Mandatory access control: you get access control whether you like it or not. Most often a system will institute a 'default' template for access control, meaning everything gets a modicum of protection.

Mandatory access control makes more sense than discretionary access control. Discretionary access control doesn't make much sense at all. Your Apple Unix uses mandatory access control, so you're good.

How?

So how do you control access on your system? There are several ways.

• Standard file permissions
• 'File flags'
• Access control lists

Standard file permissions

Standard file permissions are what Unix had from the beginning, back in the mists of time, when Ken Thompson, ably assisted by Dennis Ritchie, mapped out the fundamentals of their new hierarchical filesystem. Unix wasn't built solely to create a secure environment, but their working environment, the Computer Science Research Center at Bell Labs, with about 25 hard-nosed PhDs, required some sort of law and order. What Ken and Dennis came up with was a system to control access based on three levels of authorisation and three types of file use.

Authorisation was specific for the owner of a resource, a designated user group associated with the owner, and then everyone else.

File use was about either reading a file, writing to a file, or 'running' a file (such as a program or a script).

Ken and Den decided to display this 3x3 in the octal radix, and it's in use even today.

Arbitrarily assigning a '4' to read privileges, a '2' to write privileges, and a '1' to execute or run privileges, they had a neat system that fit perfectly into the octal box. The numerical 4, 2, and 1 are separate binary digits, so it's perfect. And when summed together, those three values add up to 7, which of course is the highest octal digit.

Access rights for resource owner, owner's group, and everyone else - normally referred to as user, group, and other - are listed in that order. So, for example, the value:

640

Means 'read and write' for the owner, 'read' for the group, and nothing for anyone else.

Running Directories

The 'eXecute' bit takes on a different meaning when it comes to directories. With regular files, the meaning's clear, but with directories, it means 'the ability to enter and list the contents of a directory'. 'Entering' a directory involves the concept of the 'current working directory', which is an 'environment setting', a sort of scratchpad value that makes administrative work a bit easier. With file paths getting inordinately long, this concept can save time (and typing).

drwxrwxrwx

File permissions can also be expressed alphabetically, as seen with the Unix tool 'ls'.

(Golden Ken Thompson rule: when naming commands, make the names as short as possible, and eliminate all the vowels. 'ls' stands for 'list'. 'rm' stands for 'remove'. 'cd' stands for 'change directory'. 'cp' stands for 'copy'. And so on. They sat at teletype machines back then, and they weren't as demented as the braintrust in Redmond.)

The ten characters in the alphabetic description above:

√ d or -: It's a 'd' if the file is a directory, otherwise mostly a dash
√ rwx: First grouping is for user, next for group, last one for 'other', if a permission is present, use an 'r', 'w', or 'x', otherwise a '-'

So the permission 640 from above becomes:

-rw-r-----

(What happens when translating the 'd' back to octal is another story coming later.)

Using only this permission system, it's easy to see that things must have mostly worked well at Bell Labs. One could close off one's own directories to prying eyes (or undesired interference). One could prevent programs from accidentally running. One could mete out access to others for reading documents or source code files without simultaneously granting them the ability to change anything. And so forth.

File Types

Unix file modes are described with not three but six octal digits. So there are three more digits yet to look at.

Two of the remaining three (still in octal) are used to denote the type of a file. Following are the Unix filetypes.

01 - named pipe or FIFO buffer
02 - character device
04 - DIRECTORY
06 - block device
10 - REGULAR FILE
12 - symbolic link
14 - socket
16 - whiteout

The only two we need look at here are the ones in UPPER CASE. (And no, Unix file types don't include things like 'Microsoft Excel File' - these types are endemic to filesystem operations only.)

The Final Bits

The final bits - expressed in a single octal digit - cover a number of different functions all at once.

Set User ID (SUID)

The 'set user ID' bit is a bit special. It's used when the owner (user) of a file is someone other than the current user, perhaps another user with a different set of privileges, perhaps the superuser 'root' who has all possible privileges. Ownership of the file must be set by this other 'user'. Then, if the current user qualifies for access through being a member of the designated group, the current user can 'run' the file. And, whilst running the file, and only when running the file, the current user assumes the general access privileges of the actual owner of the file.

Set Group ID (SGID)

The same as the above, but for groups instead. Not used as often.

Sticky Bit

The so-called 'sticky bit' has a bit of history. Originally this bit was set when the system architects wanted to know when a particular program should stay 'resident' in RAM if possible. This need isn't felt as before, and so the sticky bit today applies to directories, where it means that files, which can be added to a directory by many different users, can only be removed by the file's owner or the directory's owner. This bit was often used in the early years of OS X to protect directories at root level.

Putting it all together

Put all that together and you have the complete description for a file mode.

Type - 2 digits
Sticky/SUID/SGID - 1 digit
Permissions - 3 digits

The file mode:

100644

Thus pertains to a regular file with read/write for the owner/user, read for the group, and read for everyone.

The file mode:

104550

Pertains to a regular file with a set user bit, read/eXecute for the user and group, and zip access for anyone else.

Determining the user and group are determined separately.

The full file description block includes the following. The block contains numerical fields for the user and group (st_uid and st_gid respectively).

     struct stat { /* when _DARWIN_FEATURE_64_BIT_INODE is defined */
         dev_t           st_dev;           /* ID of device containing file */
         mode_t          st_mode;          /* Mode of file (see below) */
         nlink_t         st_nlink;         /* Number of hard links */
         ino_t           st_ino;           /* File serial number */
         uid_t           st_uid;           /* User ID of the file */
         gid_t           st_gid;           /* Group ID of the file */
         dev_t           st_rdev;          /* Device ID */
         struct timespec st_atimespec;     /* time of last access */
         struct timespec st_mtimespec;     /* time of last data modification */
         struct timespec st_ctimespec;     /* time of last status change */
         struct timespec st_birthtimespec; /* time of file creation(birth) */
         off_t           st_size;          /* file size, in bytes */
         blkcnt_t        st_blocks;        /* blocks allocated for file */
         blksize_t       st_blksize;       /* optimal blocksize for I/O */
         uint32_t        st_flags;         /* user defined flags for file */
         uint32_t        st_gen;           /* file generation number */
         int32_t         st_lspare;        /* RESERVED: DO NOT USE! */
         int64_t         st_qspare[2];     /* RESERVED: DO NOT USE! */
     };

So, given the IDs of the user and group, and given the full mode of the file in question, we (or the system) can completely determine access control.

But that's only the first access control system used.

File Flags

Right on top of the above access control system one finds the so-called 'file flags'. These flags can have the highest precedence of all access systems, but again: that's left up to the code in the operating system itself, as the bits on disk don't determine the precedence used, or even the actual meaning of the bits.

File flags are often depicted in hexadecimal, just to mix things up a bit after using octal for modes. And they're a bit different in use as well. Here they are.

00000001  user no dump
00000002  user immutable
00000004  user append
00000008  user opaque
00000010  user no unlink
00000020  user compressed
00008000  user hidden

00010000  system archived
00020000  system immutable
00040000  system append
00100000  system no unlink
00300000  system snapshot

Mostly these flags are self-explanatory. 'No dump' means you can't dump a file, 'immutable' means a file may not be modified, 'append' means a file may only be appended but not otherwise modified. 'Hidden' is an Apple-only flag, used to cue Apple's Finder to not list a file even in file dialogs.

The 'system' flags are a bit special: whilst it is possible to 'set' these flags for certain users and given adequate access permissions, it may not be possible to reset them in other than what is called 'single user mode'.

Single user mode (or 'SUM') is where you find yourself when you boot a Unix computer in a special way. On an Apple computer, you hold down ⌘S when starting, and lots of lovely text comes up, lots of stuff you'll have little time to read and little chance of comprehending. At this point in the boot process, you're not logged in. You're not even the superuser 'root'. This is equivalent to unlocking the door to a room with an old standalone machine - it's very much the same thing. And there are a few things you can do here that you cannot do once you've logged in (even as root). Resetting these system file flags is one of them.

Note that there are two 'no unlink' flags listed above, one for the user and one for the system. The one stops ordinary users from removing a file; the other stops even the superuser from touching it. (Note: 'unlink' equates to 'remove' in most cases, save where a file can be found through more than one name/path.) Note that there are other user/system pairs as well.

But that's only the second access control system.

Access Control Lists

Previously discussed, here. access control lists provide yet another level of access control. Access control lists normally preempt ordinary file permissions (but not file flags).

An access control list (ACL) contains access control entries. These are strictly ordered on some platforms, but don't seem to be on BSD Unix and derivatives, which can lead to ambiguous situations.

Access control entries are of two types: to allow or deny access to a resource. The traditional idea is to parse an ACL until it can be determined if access will be allowed or denied; contradictory entries after that point are ignored.

Access control entries pertain either to a particular user or a group. The group 'everyone' is often used to cover exactly what it says - everyone.

Access control entries can also be set for inheritance.

[Be careful when toying with ACEs: it's possible, without any privilege escalation whatsoever, to deny access to read directory attributes, meaning file listing tools and file managers won't even know who owns the resource, forcing you to escalate your account to root to remove the ACE.]

Putting it all together

The old rule 'KISS' ('keep it simple, stupid') applies as always. Ordinary file permissions should be enough for 99.99% of all cases.

Make a point of masking down your home area to prevent accidental intrusion and mishap. Make sure you don't have any 'world-writeable' files unless you specifically have a need for them. Don't grant permissions unless you know someone will need access.

Use the file flags and ACLs only when you specifically need them. You don't want to make things fancier than they need be, but it's important to understand they're there and can already be in use, in case you need to do something about them, as your default utilities on your Mac won't help you much, and you'll need to tug at your hairpiece at the command line otherwise.

A few additional articles can be found in the link section below. Some of the links lead to compendiums of even further links. Hopefully this tutorial will prove to be of help.

Summing Up

The file flags and ACLs aside, it's hard to conceive of a better access control system than that invented by Ken Thompson and Dennis Ritchie. It covers all possible permutations, divides things up in a nice way for collaborative yet secure work. Like many of the ideas and concepts used in this system from Bell Labs, it was a hallmark of the elegance and simplicity for which this system has become so renowned. If you should find it a bit impenetrable, keep in mind that life itself can be this complex - you're spared system designs predating Unix that could be downright annoying.

Full understanding of these resource protection mechanisms can never hurt and can oftentimes save you from catastrophe.

Not covered above is the actual nature of the Unix 'directory' and how its contents and applied access permissions play into exigencies on your system today.

See Also
ACL: Access Control
Protect Your Home
OS X Bibliography
It's a Way of Thinking
Managing File Attributes
CLIX False Beginners (2)
On File Management (4)

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.