Upon launching Sandbox, your view of the world is pretty plain. You may even ask yourself, "Where do I start?" To help with this confusion, let's break down the workflow of a typical Sandbox user.
This chapter is intended for users who have never used Sandbox before, but may have used Workgroup Manager or the chmod utility to manipulate access control lists.
Let's take a moment to define more fully some common terms and concepts used throughout this guide and Sandbox itself. Because Sandbox operates on folders only, and not both files and folders, the word "folder" throughout this guide can be thought of as "file or folder" under normal circumstances, but simplified here for the sake of brevity.
POSIX permissions — The traditional UNIX model for folder access settings, consisting of read, write, and execute abilities. A given folder has separate sets of these permissions for its owner, its group, and everyone else.
extended security, extended security attributes — If POSIX permissions are the standard UNIX file system security model, access control lists could be called an extension of the standard security model. As such, any volume that has ACLs in effect is said to have extended security attributes enabled. In this sense, the phrase "extended security attributes" is synonymous with "access control list". Extended security attributes take precedence over standard POSIX permissions.
access control entry (ACE) — A single rule, consisting of an entry type, user or group name, and a set of behavior flags, that is part of the the access control list for a given folder. The entry type is a modifier that either allows or denies the permissions associated with the entry's behavior flags. Entries themselves do not have specific IDs outside of the concept of an access control list.
access control list (ACL) — The collective, ordered ACEs for a given folder. By existing within an ACL, individual entries are given explicit order, beginning at ID 0 and incrementing as new entries are added. As no two entries may share a position in the ACL, the ID of each entry is unique. Lower ID numbers have higher precedence.
It's worth keeping in mind that the existence of ACL metadata on folder is independent of whether or not extended security is enabled for a volume; turning off ACLs for a specific volume does not delete the ACLs set on that volume's folders, it simply disables the effects and visibility of those ACLs and reverts the responsibility of file system security to standard POSIX permissions.
Now that we're on the same page, we can talk about how you use Sandbox from a conceptual standpoint, covering the things you do with Sandbox rather than the commands you issue to do them. In this way, having gained a clearer mental model of Sandbox's workflow, you'll find later chapters more useful.
For now, we're simply going to talk about where you can go, not necessarily how to get there.
Before we can even see the ACLs for folders on a given volume, extended security must be enabled for it. After extended security is enabled, inspect a folder may no longer present us with only POSIX permissions: we may now encounter folders with ACLs, supplanting the standard permissions set for those items and potentially their contents.
If we inspect a folder that doesn't have any entries yet, we have the ability to:
By inspecting a folder that already has an ACL containing at least one entry, we have the ability to:
Regardless of whether a folder has an empty ACL or a dozen entries, we can:
At any time, we can disable extended security for the working volume. Since this action is non-destructive and only causes ACLs to be ignored, we don't worry about any of our work being lost. Nothing is deleted; you can always re-enable ACL support at a later time.