Command-Line NetInfo Administration Tools

Managing Users Through NetInfo

Although you can create and customize users using the Accounts System Preferences pane, there are some aspects about a user account that can only be customized directly in the NetInfo database, such as the group to which a user belongs.

Understanding Sane User Account Management

It can be very useful to add groups to your system for any logically collected groups of users on your system. The Unix privilege system underlying Mac OS X contains a mechanism to allow groups of users to mutually share access to files within their group, while protecting those files from other users on the same system.

To enable this capability, you must create groups for those users to belong to and you must add their usernames to the users value list of the group. A single user can be a member of an arbitrary number of groups and can assign files that he owns to be visible to any one of (or none of) the groups to which he belongs. To make use of this capability, the user must use the command-line group ownership tools discussed in Chapter 15, "Shell Configuration and Programming (Shell Scripting)."

Starting with the release of 10.3, Apple has chosen to follow an administrative philosophy that believes that it's easiest to create a new group for each and every user that's created, and to assign each user to belong, by default, to his own group. This has the advantage that it's easy to assign a small group of users to belong to the same group as some user jim, by simply assigning them to the group jim. In other words, it makes management of groups that relate to individuals relatively easy ]all of jim's friends belong to group jim, and he can easily allow them privileged access to some of his files (although the administrator still must do the work of adding users to group jim there's no current way for jim to do this himself).

Unfortunately, this administrative philosophy works well for managing a bunch of individuals, but it doesn't work well for managing things such as project groups or users that are otherwise logically grouped on the system into large "classes" of some sort. For this sort of system use, it's more convenient to have all users that belong to some project, or that have some grouped privilege class, to have the same default group. If an individual wants to have a group-of-friends-type group, root can always create an individual group for them as well as the general-class groups. Because root has to manually add "jims friends" to group jim in the new-group-for-each-user design, it's not really any more inconvenient to create additional per-user groups for those individuals who might want to have them when using the general-class group paradigm.

If you decide to dispose of Apple's new-group-for-each-user paradigm for management of your system, you'll want to create at least one general-user group in NetInfo, typically called users, into which you can assign users who don't logically seem like staff users. Apple's Accounts pane now creates users as members of their own individual groups, and you're welcome to leave them with these default groups, but we'll also show you how you can automate the creation of users and take control of the group assignment process later in the chapter.

On the other systems we run, we have a logical distinction between staff users and normal users, so we find it convenient to mirror this with our Mac OS X installations by creating a group to assign new, nonstaff users to. On our Mac OS X machines, we created this as GID 99, with group name users. We assume this value as a default in various other locations in this book.

NOTE

In more than a few years of managing clusters of Unix machines with aggregate hundreds of users, I don't think I've come across more than a handful of situations where using Apple's current new-group-per-user paradigm would have been helpful in managing users and groups. I've come across many more instances where using the old-style paradigm of assigning all nonadministrative users to the same users group, and then creating new specific groups as needed, was a better solution. If you're going to be housing only a small number of users on your system, Apple's method is probably fine, but if you'll have many users, I expect that you'd find limiting things to a smaller number of user groups to be beneficial.

Using the NetInfo Database to Customize a User

Now you've had the opportunity to examine the NetInfo database, back it up, and use several tools to modify it. In the previous section, you saw that changes could be made in the NetInfo database and a small sampling of how these changes interact with and provide information to other tools. We make use of that idea in this section, in which you learn how to customize a user account. We use the Accounts control panel to create a user, but we customize our user by editing information in the NetInfo database.

In our example, we create a user who we want to use as our general software user. This is a specialized user whose account we want to use when compiling software for the system, but we do not want this user to be one of the administrators for the machine. We want our user to belong to a group called tire with group ID 100. We'd also like to have a specific user ID, 502, for our user, whose account we intend to call software. To create this user, do the following:

1.

Open the Accounts System Preferences pane. Click the lock icon if it's set not to allow changes. Add a new user with a short name of software. Our software user's name is skuld. Choose whatever password you prefer. Don't give your software user admin privileges.

2.

Open NetInfo Manager and select the local domain if it's not already selected. Click the lock to make changes and enter the administrator username and password.

3.

Click the groups directory and scroll through the list. Because tire is not a default group that comes with the system, you should not see a group called tire. Therefore, you must make a new group. Click any group to see what values are typically included in a group. Figure 20.8 shows the types of properties that belong to a group.

Figure 20.8. Typical properties for a group.

4.

Click groups. From the Directory menu, select New Subdirectory. A new directory called new_directory appears. Edit the name property to have the value tire. Under the Directory menu, select either New Property or Insert Property to add other property and value pairs as follows:

Property	Value
name	tire
passwd	*
gid	100
users	software

The * in the password field means that a group password is not being assigned. So far, we have only one user in our group: the user named software. As the term group implies, we can have more than one user in a group. If you wanted to add more than one user to the group, select the users property and under the Directory menu, select New Value or Insert Value. Edit the new entry to include the additional user.

5.

Select Save Changes from the Domain menu. A question to Confirm Modification appears. Click Update this copy. Now new_directory has become tire, as shown in Figure 20.9.

Figure 20.9. We now have a new group called tire with GID 100. At this time, only one user, software, belongs to the group.

6.

Click users and then click software. Now the default information about user software appears in the bottom window. If this is one of your first users, UID 502 might already be the user ID; otherwise, you can change software's UID shortly. A group ID that is the same as the UID is probably what was made. If you look at the values section for software, you can see that the Accounts pane added quite a bit of information about software to the NetInfo database.

If software were not one of the first users on my system, I would already have a user with UID 502. Because of this, I would have to either change the UID of my original user or delete the user. If the original user were not an important user, such as a user created to run demonstration commands, rather than a real user who is using the machine, I would just delete the user. If I wanted to keep my user, I could change the UID of the original user to one that wasn't already taken, and then change the UID of software to 502.

NOTE

If I decided to rearrange UIDs instead of simply deleting the user, I would also have to change the ownership of all the files that belonged to my previous user to belong to their new UID. File ownerships are stored based on numeric UID. Changing a user to a previously used UID gives that user access to and ownership of any files that still belong to that numeric UID.

For your purposes, the user ID for software might not be important. Because we want to share some of our resources with another machine that also has a user calledsoftware and whose UID is 502, it's important for us to make software's UID 502 for compatibility purposes. In both cases, we want the user software to belong to group tire. Change the GID to 100. Change the UID as appropriate for your situation. Select Save Changes from the Domain menu and click Update this copy in the Confirm Modification box. Figure 20.10 shows the updated information for our user software.

Figure 20.10. Now our user software has UID 502 and GID 100. We can see from this information that user software has been assigned a password, a home directory in /Users/software, and a default shell of /bin/bash.

7.

Click the lock to save your changes and end your ability to make further changes.

8.

Open a Terminal window, go to software's home directory, and look at the directory's contents. Take note that the directory was created by the Users pane with the default values. The update to the information in the NetInfo database, however, was not entirely reflected in the system. So, you must manually implement those changes. First, here's the default information for the software user that was created on our system:

 brezup:sage software $ ls -al total 8 drwxr-xr-x   11 software  software  374 Mar  7 10:54 . drwxrwxr-t    6 root      admin     204 Mar  7 11:04 .. -rw-r--r--    1 software  software    3 Mar  7 10:54 .CFUserTextEncoding drwx------    3 software  software  102 Mar  7 10:54 Desktop drwx------    3 software  software  102 Mar  7 10:54 Documents drwx------   17 software  software  578 Mar  7 10:54 Library drwx------    3 software  software  102 Mar  7 10:54 Movies drwx------    3 software  software  102 Mar  7 10:54 Music drwx------    3 software  software  102 Mar  7 10:54 Pictures drwxr-xr-x    4 software  software  136 Mar  7 10:54 Public drwxr-xr-x    5 software  software  170 Mar  7 10:54 Sites 

In our example, software's original UID was 502, which is still software's UID. Depending on what changes you had to make in the NetInfo database to get the desired UID, you would probably see the original UID number that belonged to software here rather than the username. If you didn't change your software user's UID, you should see software in that column, as shown here. The default GID that the Accounts pane used for creating software was GID 502, the same number as the UID, and has the same group name,software, as well. So, the information that we see for software's home directory is the information that was originally assigned to software. We have to update the information to software's directory to reflect the new information.

As root, or using sudo, in the /Users directory, change the ownership of software's directory to the software user in group tire:

 brezup:sage Users $ sudo chown -R software:tire  software Password: 

Check the results:

 brezup:sage Users $ ls -ld software drwxr-xr-x   11 software  tire  374 Mar  7 10:54 software brezup:sage Users $ ls -l software total 0 drwx------    3 software  tire  102 Mar  7 10:54 Desktop drwx------    3 software  tire  102 Mar  7 10:54 Documents drwx------   17 software  tire  578 Mar  7 10:54 Library drwx------    3 software  tire  102 Mar  7 10:54 Movies drwx------    3 software  tire  102 Mar  7 10:54 Music drwx------    3 software  tire  102 Mar  7 10:54 Pictures drwxr-xr-x    4 software  tire  136 Mar  7 10:54 Public drwxr-xr-x    5 software  tire  170 Mar  7 10:54 Sites 

If you changed the UID of a user who was originally assigned UID 502, look at that user's home directory and make the appropriate ownership changes.

Enabling the root Account

As mentioned earlier, the administrator account is a powerful account. But the most powerful account on a Unix machine is the account called root. People also refer to root as the super user, but the account name itself is root. On most Unix systems, the first available account is the root account. In Mac OS X, however, the root account is disabled by default as a security precaution.

At some time, however, you might find it necessary to enable the root account. The root account can modify system settings, modify files it does not own, modify files that can't be written to by default, modify a user's password, install software, become another user without having to know the password of that account, and so on. In other words, root can do anything anywhere, making the power of root immense. Because root has so much power, the only users who can become root are users with administrative privileges. Because a user with administrative privileges can become the root user, you should assign these capabilities to only completely trusted individuals.

If you choose to enable the root account, remember to use it with caution. Although the root account might provide some extra utility, you could accidentally wipe out your system if you don't pay careful attention to what you type. In addition, the root password you choose should be difficult to guess. Finally, become the root user for only as long as necessary to complete the task at hand.

With the presence of an administrative user, it might be a long time, if ever, before you discover a need to enable the root user. You can take many approaches for dealing with the root user from ways to use root without enabling the root account to actually enabling the root account.

Let's take a look at four different ways to gain root access to your system. Although you can choose whichever method you like, it's useful to understand that even though some of these methods appear to work magic, they all accomplish very much the same thing.

The root user is disabled because it does not have a valid password set. Because there are a number of ways to set a password, there are also several ways to enable root, including one method (the first method we'll look at) that was designed specifically for assigning the root account password and only the root password. In addition, you'll see how the sudo command can provide root-level access even when the root password is disabled. We recommend that users access the root account only when absolutely necessary.

Using the NetInfo Manager Utility

The NetInfo Manager Utility provides a graphical method for enabling the root user.

1.	Start the NetInfo Manager utility and click the lock to make changes.
2.	For Mac OS X 10.2 and later, select Enable Root User from the Security menu. For Mac OS 10.1 and 10.0, select Security from the Domain menu. Then choose Enable Root User from the submenu. Unless you've previously set a root password, a message appears with a NetInfo error indicating that the password is blank.Click OK.
3.	Enter the root password you want to use and then click Set. Remember that the root password should not be easily guessable.
4.	Enter the password again for verification and then click Verify.
5.	Click the lock button again to prevent any further changes. Then close NetInfo Manager.

Figure 20.11 shows an example of what an enabled root account looks like in NetInfo Manager. Note that the password field no longer has a single * in it; instead it has a string of *s.

Figure 20.11. The root account has been enabled on this machine. Note the * that was in the password field has been replaced with several *s.

Using the Mac OS X Installation CD

Because the Mac OS X installation CD comes with an option to reset a user's password, you could use the installation CD itself to enable the root user.

To enable the root account using the Mac OS X installation CD, do the following:

1.	Insert the Mac OS X CD.
2.	With the CD in the CD-ROM drive, reboot the machine. Hold the C key while the machine reboots.
3.	Wait for the Installer to appear and then select the Reset Password option under the Installer menu.
4.	Select the Mac OS X disk that contains the root account you want to enable. If a spinning CD icon appears after you've chosen the Reset Password option, don't wait for the spinning to end to select your Mac OS X disk. The System Administrator (root) user appears as the default user in a pop-up menu that lists all the users.
5.	Enter a new password and then reenter the password for verification. Click Save. Click OK when the Password Saved box appears.
6.	Quit the Password Reset application, quit the Installer, and click Restart.

Using sudo to Enable the root Account

Recall that the sudo command is used to execute a command that root might execute. One way to enable the root account is to use sudo to execute passwd, which is a command used to change passwords.

Here's an example:

 brezup:sage sage $ sudo passwd root  Password: Changing password for root. New password: Retype new password: brezup:sage sage $ 

The password that you initially enter is your password. Then you supply a password for root and reenter it for verification. If you mistype the password, you're prompted again, as shown in this example:

 brezup:sage sage $ sudo passwd root Password: Changing password for root. New password: Retype new password: Mismatch; try again, EOF to quit. New password: Retype new password: brezup:sage sage $