Project 8. Manage File PermissionsThis project covers permissions and how they affect your access to the file system. You'll learn how to interpret permissions and how to modify them. Users and groups, covered in Project 7, are intimately related to permissions. Unix and its file system (its method of organizing and storing information) were designed from the ground up to keep data secure on computers shared by multiple users. Users, Groups, and Permissions form the foundation of this secure file system (and that of Mac OS X as well). Unix employs users and groups (see Project 7) to identify you and associate you with the files you own and the files you share. Permissions are assigned to each file individually. They mark out your personal "turf" and the extent of your access to remainder of the file system that is, which files and directories you can see and change, and which programs you can run. What are Permissions?Every file (including directories and executables) is owned by a particular user and has an associated group. Permissions define those files you may view (read), write to, and execute. Three sets of read/write/execute (rwx) permissions are defined: one for the owner, one for members of the associated group, and one for everyone else. (The root user has read, write, and execute permissions on all files.) Your permissions for a given file are determined as follows:
Permission TripletsPermissions are displayed in three sets of triplets. Reading from left to right, they apply to the owner, members of the associated group, and everyone else. They are interpreted as r for read access granted, w for write access granted, and x for execute permission granted. A dash (-) means permission is not granted. As an example, list the contents of your home directory. $ ls -l total 0 drwx------ 4 saruman saruman 136 12 May 18:59 Desktop drwx------ 15 saruman saruman 510 4 May 12:11 Documents ... drwxr-xr-x 5 saruman saruman 170 4 May 22:04 Public ...
The directories Desktop and Documents are private to saruman, whereas Public can be read and executed (but not written to) by members of group saruman and in fact by everyone. This is consistent with Public's being a directory that others can view but cannot change. Note that if an enclosing directory does not grant read/write permissions, the files in that directory cannot be accessed, no matter what permissions they themselves may carry. Permissions on Mac OS X System FilesThe file system in Mac OS X can be split into three areas with regard to permissions:
The split works well: Demarcation of the Unix core allows the nonexpert Mac user to be an administrator, but without any danger of hosing the core installation. This users/administrators/root split is achieved by using groups. An administrator user is made a member of the group admin. Any file that is to be writable by administrators, but not by normal users, is associated with admin, and write permission is granted to the group. Viewing permissions in /Applications confirms this. $ ls -ld /Applications drwxrwxr-x 28 root admin 952 13 May 11:18 /Applications $ ls -l /Applications total 0 drwxrwxr-x 3 root admin 102 15 May 2004 Address Book.app drwxrwxr-x 7 root admin 238 24 Apr 06:47 AppleScript ... drwxrwxr-x 3 root admin 102 11 Aug 2004 iSync.app drwxrwxr-x 4 root admin 136 13 May 11:18 iTunes.app A normal user is able to execute all applications but cannot modify them; no write access is granted to others. However, the associated group is admin with read and write access granted. An administrative user, being a member of group admin, can therefore modify an application (install or update it). Tip
The directory /System/Library contains the Unix core and is protected from administrative users. Only root may modify this area. $ ls -ld /System/Library drwxr-xr-x 52 root wheel 1768 24 Apr 06:49 /System/Library/ $ ls -l /System/Library total 90144 drwxr-xr-x 228 root wheel 7752 Apr 8 01:59 Automator drwxr-xr-x 11 root wheel 374 Apr 8 01:57 CFMSupport drwxr-xr-x 9 root wheel 306 Jun 12 21:45 Caches ... Take Command of PermissionsUse the command chmod to change file modes (permissions). You must specify to whom the new permissions apply by using the following encoding:
what permissions are to be applied:
and how they are to be applied:
Here are some examples. Set permissions to rwx r-x r-- (rwx for users, r-x for group, r-- for others): $ chmod u=rwx,g=rx,o=r file Remove read access from others, and add write access to the group. $ chmod o-r file $ chmod g+w file Add execute permission for everyone. Use one of these. $ chmod +x file $ chmod a+x file $ chmod ugo+x file Finally, set the group permissions to equal those of the owner. $ chmod g=u file Check out the Unix man page for chmod. It has a recursive mode when you need to modify all files in the directory hierarchy. (See "Recursion" in Project 2.) Set Default PermissionsNew files are created with the permissions rw- rw- rw- minus the permissions specified by the umask. New directories are created with the permissions rwx rwx rwx minus the permissions specified by the umask. Use the command umask to display and set it. To see the current value of umask, type $ umask 0022 0022 is in octal and means --- -w- -w-. (See the sidebar "Permissions in Octal.") Therefore, after the umask value is applied, a file is created with permissions rw- r-- r--, and a directory is created with permissions rwx r-x r-x. Setting the mask to 077 (--- rwx rwx) causes new files to be created with permissions rw- --- --- and new directories with permissions rwx --- ---. To set the umask to the new value, type $ umask 077 Append-Only Directories: The Sticky BitA user who has write permission for a directory can delete any file from that directory, whether or not she has write permission on the file itself. This may seem odd (the reason is that deletion changes directory contents without changing any actual file contents), and it's certainly not always desirable. Everybody has read and write permission for the shared directory /Users/Shared, for example, but users shouldn't have a license to delete one another's files arbitrarily. To address this concern, Unix permissions feature something called the sticky bit. The secret to preventing unwanted file removal lies in making a directory append-only. Unprivileged users may add files to an append-only directory but may not delete them. Such a directory is termed sticky and has the sticky bit set. Learn More
For example, the Shared directory is sticky. $ ls -ld /Users/Shared drwxrwxrwt 10 root wheel 340 6 May 20:57 /Users/Shared Stickiness is indicated by a t, replacing what would normally be an x in the others' permissions triplet. If x were not set, the sticky bit would be displayed as T instead. Command chmod sets and clears the sticky bit. $ chmod u+t directory You may also use g+t, which has exactly the same effect; o+t has no effect. A file in a sticky directory may be removed only by the owner of the file; the owner of the directory, provided that he has write access for the directory; and (of course) root. Executing as Another UserWhen you execute a command such as rm, you can remove only files for which you have the appropriate permissions. Another user issuing the same command sees a different set of permissions and can remove only files for which they have the appropriate permissions. The mechanism that makes a particular command behave differently depending on who invoked it is inheritance. When a command is executed, it inherits the UID and GID of the user who executed it. It runs on behalf of that user and enjoys the same file-system permissions (and restrictions). Under certain circumstances, a command may inherit a UID or GID different from that of the executing user. Commands issued by the command sudo (short for substitute user do) are one such example. Running sudo as an intermediate lets a user confer the UID and GID of the super-user (or any other user) to a command instead of his own. (Indiscriminate use of sudo would create obvious security concerns, so only users with Administrator privileges can run it.) The s-BitThe s-bit is best explained by example. The ability of sudo to change the UID of its user is related to the permissions set on the sudo program file itself and a special permission setting known as the s-bit. To see it in action, let's examine the sudo executable: $ ls -l /usr/bin/sudo -r-s--x--x 1 root wheel 101028 4 May 11:59 /usr/bin/sudo The presence of an s in place of an x in the owner's permissions triplet indicates that the s-bitthe set user ID on execution (S-UID) bitis set. When sudo is executed, instead of inheriting the UID of the user by whom it was executed, it inherits the UID of the user who owns the file. In this case the owner is root, and sudo runs with root permissions. When sudo invokes a command, that command inherits the UID, so it too has root status. Use chmod to set the S-UID bit. $ chmod u+s my-command You can set an s-bit in a file's group-permissions triplet as well. $ chmod g+s my-command As you'd expect, this set group ID on execution (S-GID) bit allows execution of a file using the GID (and related group permissions) of its associated group.
Commands Inherit Permissions, TooUse of the S-UID and G-UID bits has serious security implications. If the file my-command in this example were written to delete some of my files, any user who can execute it can now delete those files regardless of their native permissions. The command is running with my UID and GID; it is effectively running as me. The command may call another command such as rm, and rm in turn inherits my UID and GID. In the general case, any command invoked by the S-UID-enabled my-command, and any command invoked by that runs as me. If my-command is part of a pipe, the S-UID and S-GID bits do not influence commands farther along the pipe, because subsequent commands are called by the shell and not by my-command.
|