17.2. Enabling the Root Account | Mac OS X Snow Leopard: The Missing Manual (Missing Manuals)

< Day Day Up >

17.1. Changing Permissions with Terminal

Permissions is a largely invisible, but hugely important, Mac OS X and Unix feature. The behind-the-scenes permissions setting for a file or folder determines whether or not you're allowed to open it, change it, or delete it. Permissions are the cornerstone of several important Mac OS X features, including the separation of user accounts and the relative invulnerability of the operating system itself.

You can get a good glimpse at the permissions settings of a file or folder in the Get Info box; see Section 12.10.1 for a discussion. But even there, you're not seeing all of the permission settings Unix provides, and every now and then, you might want to. Suppose, for example, that you're a teacher in charge of a computer lab containing 25 Macs. On each computer, you've created Standard accounts (see Chapter 12) for five students, for a total of 125 student accounts.

Soon after the students start using the lab, you notice a bit more giggling and frantic typing then you'd expect from students researching Depression-era economics. You nonchalantly stroll to the end of the room and do a quick about-face at one of the desks. Aha ”iChat! Horribly depressed by the comments you read there regarding your fashion sense, you vow to keep students from using that application ever again.

You have several options:

Delete iChat from the Applications folder . Unfortunately, the Computer Club meets in your classroom after school, and its members routinely use iChat to communicate. (Talking out loud, after all, is so 20th century.)
Use Parental Controls . You can open System Preferences, click Accounts, click Parental Controls, click to configure Finder & System, select Some Limits, and turn off the iChat checkbox from the list of allowable applications. Repeat 124 times.
Buy, install, and configure Mac OS X Server . Then you can create and configure workgroups with any permission settings you wanted. (Apple offers a four-day training course if you get stuck.)
Use Terminal . Go to a Mac, fire up Terminal, and type a quick command to turn off iChat's execute permissions for Standard account holders. (This process won't affect the Computer Club, because its members all have Administrator accounts.) Repeat only 24 times.

In fact, if walking to each machine is too much work, you can even use the ssh technique described in Chapter 22 to run the command remotely from a single machine, while seated in the comfort of your own teacher's chair .

It'll take several pages to work through this example. But in the process, you'll learn an amazing amount about Terminal and the Unix underpinnings of Mac OS X.

17.1.1. Looking at Permissions

In general, when you double-click a file icon in the Finder, it opens either as a program or opens into a program (if it's a document).

But as noted on Section 5.1.3, most Mac OS X application icons in the Finder are really folders posing as single files. Inside the folder, or package, are all the files that application depends on to run, including the actual application file itself, the one that opens when you double-click the package icon. If you turn off the execute permission for that inner nugget, you prevent it from running ”and, as in this classroom example, you can turn it off only for certain kinds of account holders.

To inspect the permissions for iChat, open the Applications folder. Control-click the iChat icon. From the contextual menu that appears, choose Show Package Contents. When you do, a new Finder window opens, revealing the contents of the iChat application package.

Open the Contents MacOS folder; inside you'll find the individual iChat program file. (Nobody would ever bother opening iChat by double-clicking this icon, but it's possible.) You could inspect its permissions by highlighting the inner iChat icon and then choosing File Get Info. Expand the Ownership and Permissions section, and then the Details section.

Now try the same thing the Unix way. To view the ownership and permissions information within Terminal, use the ls command like this:

 ls -l /Applications/iChat.app/Con- tents/MacOS

The -l flag produces a long list ”an expanded display showing extra information about each item in the directory, in this case its single iChat file. Terminal's response is something like this:

 total 4400 -rwxrwxr-1root ad min2252792Mar2021:07iChat

Thanks to the -l option, the first line displays the grand total size of all the loose files in the directory: 592. (It's measured in 512-byte blocks. If you also included the -k flag, you would see this measurement in kilobytes.)

Next you see the name of the one inhabitant of the MacOS directory: iChat . (If there were more, you would see each item on its own line.) But what on earth is -rwxrwxrx? Is Terminal having a meltdown?

Not at all; you're just seeing more Unix shorthand, listed in what are supposed to be helpful columns . Figure 17-3 breaks down the meaning of each clump of text.

Type . The first character of the line indicates the file type ”usually d (a directory), l (a symbolic link ”the Unix version of an alias), or, as in this case, a hyphen (a file).
File Mode . Rammed together with the type (like this: rwxrwxr-x ) is a string of nine characters . It indicates, in a coded format, the actual access permissions for that item, as described in the next section.
Owner . Terminal's response also identifies the account name of whoever owns this file or directory, which is usually whoever created it. Remember that root means that Mac OS X itself owns it. That's why even administrators generally aren't allowed to delete directories that bear "root" ownership.

Note: In the Finder's Get Info windows , you may see ownership listed as System . That's Apple's kinder, gentler term for root .
Group . After the owner comes the name of the group that owns this file or directory. "Wheel," as in "big wheel," indicates the group with the highest powers (administrators are not part of this group); the "admin" group contains all administrators.

Note: If you inspect the icons in a Home directory, you find that they belong to a group that's named after your account. When you created an account named chris , Mac OS X created a chris group (with only one member), and makes every new icon part of it.Everything in Chris's Home directory, then, has chris as both owner and group, which, in Panther and Tiger, ensures greater security than what came before. (In those versions, everyone belonged to a common group called staff , and everyone's files were owned by that group. In fact, if you've upgraded to Tiger from Jaguar, you'll find that your old Home folder icons are still owned by the staff group.)

Figure 17-1. Here's one magnified line of what the ls -al command produces. The parts you care about are highlighted.
Pathname . At the end of the line (following the file's size and date) comes the path of this file or directory, relative to the listed directory.

17.1.2. File-Mode Code

To understand the coded nine-character file mode section, you need a good grasp of the topics covered in Chapter 12. There you'll find out that as you create new files and directories, you can specify who else is allowed to see or make changes to them. In fact, you can specify these permissions for three different categories of people: the owner (usually yourself), your group (Section 12.10.2), and everyone else.

The file-mode column is made of three subcolumns (Figure 17-2), which correspond to those same three categories of people: owner, group , and everybody else .

Figure 17-2. If you look very closely and move your nose right up against the screen, you'll see that the file-mode column isn't just a string of random letters ”it's three distinct sets of information that tell you who's allowed to do what.

Within each sequence, three characters describe the read (r), write (w) , and execute(x) permissions that this person or group has to this file or directory (more on these concepts in a moment). A hyphen (-) means, "Nope, this person isn't allowed this kind of access." In Figure 17-2, you can see that, if you were the owner of this file, you could do everything you want to it ”because there are no hyphens.

There's an x in all other columns too, meaning that anyone can execute (launch) this file. Since there's also a w in both the owner and group columns, those user categories could, in theory, even make changes to the file (although there would never be a reason to do so).

The three forms of access ”read, write, and execute ”have slightly different meanings when applied to files and directories:

Read access to a file means that someone can open and read it. (In the case of a program like iChat, the system needs to "read" the file on your behalf in order to run it.) Read access to a directory (folder), on the other hand, just means that someone using Terminal can see a list of its contents using a command like ls .
Write access to a file means that someone can modify and save changes to it. Write access to a directory means that someone can add, remove, and rename any item the folder contains (but not necessarily the items within its subdirectories).

Note: Turning off write access to a certain file doesn't protect it from deletion. As long as write access is turned on for the folder it's in , the file is still trashable.To protect a certain file from deletion, in other words, you must also worry about the access settings of the folder that encloses it.
Execute access , when applied to an application, means that people can run that particular program. (In fact, Unix distinguishes applications from ordinary files by checking the status of this setting.)

Of course, you can't very well "run" a directory. If this x bit is turned on for a directory, it's called the searchable bit (as opposed to the execute access bit), and it means that you can make it the working directory, using the cd command. You still can't see what's in the folder if you don't also have read permissions, but you're welcome to read or copy a file in it as long as you know its full pathname.

17.1.3. Group Detective Work

Back to the task of keeping iChat from launching. The x in every user category tells you that anyone can run this program. Your mission, should you choose to accept it, is to change these settings so that one class of account holder can run iChat (Admin), but not another (Standard).

As you've seen, every file's set of permissions identifies both an owner and a group. The group that owns the iChat file is admin . As you would expect, the Admin class of users is part of the admin group, so administrators and anyone else in the admin group will have no trouble running the program.

You just have to make sure that no other account holders ”Standard ones ”are also part of the admin group. That's easy enough to find out.

To find out what Unix groups you belong to, type groups in Terminal and press Enter. On the next line, Terminal types out a list of the groups that include your account; if you have an Administrator account, it's probably admin, appserverusr, appserveradm , plus the one named for your account ( chris , for example).

But you want to find what groups incorporate Standard account holders. To determine what groups someone else's account belongs to, type groups robin (or whatever the account name is). You'll probably see that Robin belongs only to the Robin group. And, in fact, you would find this to be true for all Standard account holders.

All right then: The admin group contains only Admin users. As far as permissions are concerned , then, Standard account holders fall into the everyone else category.

You just need to turn off iChat's execute permissions for everyone else , then, to complete your task. Doing so allows only the file's owner (root) and members of its group (admin) to execute the file (that is, to open the program). All other account holders ”that is, Standard account holders ”are out of luck. They'll actually have to pay attention in class.

17.1.4. chmod (Change Mode)

The Unix command for changing file modes (permissions) is chmod (for change mode).

Here's the command you use on the iChat file:

 chmod o-x /Applications/iChat.app/Con- tents/MacOS/iChat

And here's how to understand it.

The command line begins, naturally, with the chmod command itself, and ends with the pathname of the iChat file.

In between are three characters that make up the three parts of a mode-change clause: o-x .

The first character, o , represents the class of user that the change affects. In this spot, you can type u to symbolize the file's owner, g for its group, o for other (everyone else), and a to indicate all three classes at once.

The second character represents the operation to perform, which in most cases is either to add a permission (use the + symbol) or remove one (use the “ sign).

The final character specifies which permission to change: r for read, w for write, or x for execute.

The complete chmod command provided above, then, says, "Remove the execute permissions for others," which is precisely what you want to do.

17.1.5. Permission to Change Permissions

If you actually try the chmod command described above, however, you get only an error message ("Operation not permitted").

Only the owner of an item can change its permissions. And you're not iChat's owner; root is (that is, Mac OS X itself).

So how do you solve the problem? One solution would be to turn on the root account as described on Section 12.9, and then log on as root . Then you'd be the superuser and could do any darned thing you like. But not only is that a lot of time and hassle, involving a trip to the NetInfo Manager program and logging out, it's also an extreme step. Turning on the root account always entails a security risk.

Instead, you could always open the Get Info window for the iChat application file, make yourself the owner, and then type in your name and password to prove you're an administrator. Then open Terminal, use the chmod command now that you're the file's owner, return to the Finder, open Get Info again, and change the file's permissions back to root .

For a Unix guru, that's an awful lot of steps for something that should take only a few keystrokes. As it turns out, the final possibility is quick and easy, which explains its popularity in Unix circles. It's the sudo command.

17.1.5.1. sudo

sudo is a cool command name. Technically, it's short for superuser do , which means that you're allowed to execute any command as though you'd logged in with the root (superuser) account ”but without actually having to turn on the root account, log out, log back in again, and so on.

It's also a great command name because it looks as though it would be pronounced "pseudo," as in, "I'm just pretending to be the root user for a moment. I'm here under a pseudonym." (In fact, you pronounce it "SOO-doo," because it comes from superuser do . In the privacy of your own brain, though, you can pronounce it however you like.)

Note: Only people with Administrator accounts can use the sudo command.

If you have the root account ”or can simulate one using sudo ”you can override any permissions settings, including the ones that prevent you from changing things in the Applications directory (like iChat).

Finally, you're ready to change the permissions of that infernal iChat application file. To use sudo , you must preface an entire command line with sudo and a space. Type this:

 sudo chmod o-x /Applications/iChat. app/Contents/MacOS/iChat

Taken slowly, this command breaks down as follows :

sudo . "Give me the power to do whatever I want."
chmod . "Change the file mode "
o-x . " in this way: remove execute permission for others "
/Applications/iChat.app/Contents/MacOS/iChat / . " from the file called iChat, which is inside the Applications iChat.app Contents MacOS folder."

The first time you run sudo , you're treated to the characteristic deadpan humor of programmers worldwide: "We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: 1) Respect the privacy of others, and 2) Think before you type. 3) With great power comes great responsibility."

In other words, sudo is a powerful tool that lets you tromp unfettered across delicate parts of Mac OS X, so you should proceed with caution. At the outset, at least, you should use it only when you've been given specific steps to follow, as in this chapter.

Now sudo asks for your usual login password, just to confirm that you're not some seventh- grader up to no good. If you are indeed an administrator, and your password checks out, sudo gives you a five-minute window in which, by prefacing each command with sudo , you can move around as though you're the all-high, master root account holder. (If you don't use sudo again within a five-minute span, you have to input your password again.)

Now whenever anyone who isn't an administrator tries to open iChat, its icon bounces just once in the Dock before dying painlessly.

To restore its original permissions, use the same command, but replace the “ with a +, like this:

 sudo chmod o+x /Applications/iChat. app/Contents/MacOS/iChat

Note: Whenever Mac OS X's Repair Permissions function is run (either automatically, which happens each time you install a Mac OS X update, or manually, using Disk Utility), iChat returns to its original permissions settings. You have to rerun the command if you want its protections in place.

UP TO SPEED
Beware the Dread Typo

Use sudo with caution, especially with the rm command. Even a single typing error in a sudo rm command can be disastrous.

Suppose, for example, that you intended to type this:

sudo rm -ri /Users/Jim/Pictures

but you accidentally inserted a space after the first slash, like this:

sudo rm -ri / Users/Jim/Pictures

You've just told Terminal to delete all data on all drives !

Because of the extra space, the rm command sees its first pathname argument as being only /, the root directory.

The -r flag means "and all directories inside it."

Good thing you added the -i flag, which instructs Mac OS X to ask you for confirmation before deleting each directory. It's almost always a good idea to include -i whenever you use sudo with rm .

History buffs (and Unix fans) may remember that Apple's first iTunes 2 installer, released in October 2001, contained a tiny bug: the tendency to erase people's hard drives. (Oops!) Apple hastily withdrew the installer and replaced it with a fixed one. Behind the scenes, an improperly formed rm command was the culprit.

17.1.6. Protecting Files En Masse

It could happen to you. You've got yourself a folder filled with hundreds of files ” downloaded photos from your digital camera, for example. Most are pretty crummy, but the ones you took in Tahoe (and therefore have Tahoe in their file names ) are spectacular. You want to protect those files from deletion without having to turn on the Locked checkbox (Section 2.7.4) of every file individually.

Here again, you could operate in the Finder, just like ordinary mortals . You could use Spotlight to round up all files with Tahoe in their names, highlight all of them in the search results window, choose File Get Info, and turn on Locked, thus protecting all of them at once. But doing it the Unix way builds character.

When you turn on a file's Locked checkbox, Mac OS X turns on an invisible switch known to Unix veterans as the user immutable flag . Not even the superuser is allowed to change, move, or delete a file whose user immutable flag is turned on.

The command you need to change such flags is chflags ”short for change flags , of course. You can always read its man manual (see Section 16.3.6.1) to learn all the different flags it can change; for now, though, all you care about is the user immutable flag.

You can follow the chflags command with three arguments: its own option flags, the file flags, and the pathname of the file whose flags are being changed. In this case, the flag you care about is called uchg (short for user changeable ; in other words, this is the immutable flag).

GEM IN THE ROUGH
.command Files

You can help to combat repetitive stress syndrome by saving any long, often-typed, command line as a .command file . Double-clicking the file opens a new Terminal window, performs the command, and then exits the shell ”all automatically.

Creating .command files requires two steps.

First, create a new document in a text editor like Text-Edit. (Check TextEdit Preferences to make sure you create a plain-text document.)

Type in the entire command that you want to memorialize ( sudo chmod o-x /Applications/iChat. app/Contents/MacOS/iChat , for example). Save the document with a name ending with the .command extension ”for example, iChatOff.command . (As a bonus, documents with this extension appear with a spiffy icon in the Finder.)

Next, you'll need to make that file itself executable by using the chmod command, as described previously. If, for example, you want only the owner of the iChatOff. command file to be able to execute it (that is, you), you would type: chmod u+x iChatOff.command .

Thereafter, you can simply double-click the .command file to open and run it. (Since you used the sudo command in this example, you first have to provide your password.)

If the object of the .command file's attention sits in the same location on each Mac, you could even burn the iChatOff.command to a CD, roam to each machine, insert the CD, and double-click the .command file, thus further reducing the amount of effort required to apply its magic to many Macs.

To protect all of the Tahoe shots in one fell swoop, then, here's what you'd type at the prompt:

 chflags uchg ~/Pictures/*Tahoe*

The asterisks are wild cards that mean, "all files containing the word Tahoe in their names." So in English, you've just said, "Change the immutable flag (the Locked checkbox setting) for all the Tahoe files in my Pictures folder to 'locked.'"

Tip: To unlock a file, thus turning off its uchg flag, just add the prefix "no," like this: chflags nouchg ~/Pictures/*Tahoe* .

To view the results of your handiwork, you can always switch to the Finder, where you'll see that the Tahoe files now have their Locked checkboxes turned on. Or, to confirm your work right in Terminal, issue this command: ls -lo ~/Pictures (or any other path to a folder containing locked items). That's the familiar ls (list) command that shows you what's in a certain directory, followed by an -l flag for a more complete listing, and an -o flag that produces a "flags" column in the resulting table.

In any case, Terminal might spit out something like this:

 total 830064 -rw-r r 1 chris chris - 15 8280000 Jun 16 20:05 Sunset.jpg -rw-r r 1 chris chris uchg 58560000 Jun 16 20 :05 NewMoon. jpg -rw-r r 1 chris chris uc hg 107520000 Jun 16 20:05 Tahoe.jpg -rw-r r 1 chris chris uc hg 100560000 Jun 16 20:05 Buddy.jpg

The fifth column, the product of the -o flag, lists any file flags that have been set for each file. In this case, three of the files are listed with uchg , which represents the user immutable (locked) flag. (The hyphen for the first listed file means "no flags" ”that is, not locked.)

< Day Day Up >