Project8.Manage File Permissions


Project 8. Manage File Permissions

This 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:

  • If you are the owner of the file, you have the permissions stated for the owner.

  • If you do not own the file but belong to the associated group, you have the permissions stated for members of the group.

  • If neither of the above applies, you have the permissions stated for everyone else (others).

Permission Triplets

Permissions 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 ...


Execute Permission on Directories

You may be wondering what execute permission means for a directory. Read permission allows listing of the directory contents. But without execute permission, you cannot create a new file, edit a file, or cd into the directory.


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 Files

The file system in Mac OS X can be split into three areas with regard to permissions:

  • Home directories. Normal users maintain only their own home directories.

  • Applications and the shared library. Administrator users also maintain the shared library and applications.

  • The Unix core. This is the domain of the root user.

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

To learn the attributes of a directory (total size, permissions settings, etc.), use ls with the -ld option pair. Option d tells ls to report on a directory itself, rather than on its contents.


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 Permissions

Use the command chmod to change file modes (permissions). You must specify to whom the new permissions apply by using the following encoding:

  • u for user (the owner)

  • g for associated group

  • o for others

  • a for all, equivalent to ugo

what permissions are to be applied:

  • r for read

  • w for write

  • x for execute

and how they are to be applied:

  • = to set the permissions exactly as stated (absolute mode)

  • + to add permissions to those already granted (relative mode)

  • - to remove permissions from those already granted (relative mode)

Permissions in Octal

As shorthand for the nine-letter triplet designations, file permissions can be specified using octal numbers as arguments for chmod (in absolute mode) or umask (described later in this chapter). To determine a file's octal number, convert each of its permission triplets to a three-digit number by substituting 1 for each letter and 0 for each dash. (Permission rwxr-xr-- TRanslates to 111 101 100.) Next, read each three-digit set as a binary number and convert it to its base-10 (or, more strictly, base-8) equivalent (picking up on the earlier example, 111=7; 101=5; 100=4). String the resulting digits together to get the octal number. (For the example, it's 754.) Initial zeroes are optional in octal numbers (066 is the same as 66). We then apply the permissions using

$ chmod 754 file



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 Permissions

New 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 Bit

A 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 information on sudo, see "How to Become the Root User" in Project 2.


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 User

When 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-Bit

The 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.

S-UID on Scripts

For security reasons, S-UID on scripts is ignored. There are too many covert ways in which to turn a script to the Dark Side.


Commands Inherit Permissions, Too

Use 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.

More Octal

The s- and t-bits can be specified using octal format. Pass a four-digit octal number to chmod, where the first digit specifies the s- and t-bits, and the remaining three specify permissions as described previously. To determine the top octal digit, convert the s- and t-bits to a three-digit binary number, using 1 to set a bit and 0 to clear it. The bits are in this order: S-UID S-GID Sticky.

To set the S-UID and the S-GID bits but clear the Sticky bit, use 110 or 6 octal. One might use

$ chmod 6755 my-command


To set the Sticky bit only, use 001 or 1 octal.

$ chmod 1755 my-¬     directory






Mac OS X UNIX 101 Byte-Sized Projects
Mac OS X Unix 101 Byte-Sized Projects
ISBN: 0321374118
EAN: 2147483647
Year: 2003
Pages: 153
Authors: Adrian Mayo

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net