Chapter 11

Managing User Accounts

Adding and managing users are common tasks for Linux systems administrators. User accounts keep boundaries between the people who use your systems and between the processes that run on your systems. Groups are a way of assigning rights to your system that can be assigned to multiple users at once.

This section describes not only how to create a new user, but also how to create predefined settings and files to configure the user's environment. Using tools such as the useradd and usermod commands, you can assign settings such as the location of a home directory, a default shell, a default group, and specific user ID and group ID values.

Creating User Accounts

Every person who uses your Linux system should have a separate user account. Having a user account provides each person with an area in which to securely store files, as well as a means of tailoring his or her user interface (GUI, path, environment variables, and so on) to suit the way that he or she uses the computer.

You can add user accounts to most Linux systems in several ways. Fedora and Red Hat Enterprise Linux systems use the User Manager window (system-config-users) utility on the desktop. From Red Hat Enterprise Linux, select System ⇒ Administration ⇒ Users & Groups, and type the root password when prompted. When the window appears, select the Add User button. Figure 11.1 shows an example of the User Manager window and the Add New User pop-up.

Figure 11.1 Add user and group accounts from the User Manager window.

You are now ready to begin adding a new user account to your Linux system. Here are the fields you need to fill in:

• User Name—The name used to log in as this user. When you choose a username, don't begin with a number (for example, 26jsmith). Also, it's best to use all lowercase letters, no control characters or spaces, and a maximum of eight characters. The useradd command allows up to 32 characters, but some applications can't deal with usernames that long. Tools such as ps display user IDs (UIDs) instead of names if names are too long. Having users named Jsmith and jsmith can cause confusion with programs (such as sendmail) that don't distinguish case.
• Full Name—The user's real name, typically used with upper- and lowercase letters as the user would write it in real life. Technically, this information is stored in the comment field of the passwd file but, by convention, most Linux and UNIX systems expect this field to hold each user's full name.
• Password, Confirm Password—The password should be at least eight characters, and contain a mixture of uppercase and lowercase letters, numbers, and punctuation. It should not contain real words, repeated letters, or letters in a row on the keyboard. As root, you will get a warning, but can still set the password any way you like. A regular user, trying to change a password later, would be restricted to following the standards set.
• Login Shell—The bash shell is used by default. You can, however, select from a list of shells that are installed on your system. Whatever you set will be used as the default shell when the user logs in or opens a Terminal window.
• Create home directory—With this box selected, a home directory is created for the user if it doesn't already exist. The home directory, by default, will be /home/user, where user is replaced by the username. You can use a different location, but /home is the standard place.
• Create a private group for the user—With this check box set, the primary group assigned to this user will be a new group that is the same as the username (in this case, mary). Other Linux systems assign all users to a group named users (user ID 100). But RHEL and Fedora use a private group in this way.
• Specify user ID manually—If unchecked, the user is assigned the next numeric user ID. User IDs start at 500, although on some Linux systems, they have started setting the first user IDs at 1000. With the box checked, you can use any user ID you like. Keep in mind that if you specify the user ID manually, you risk duplicating user IDs. (The user ID is the actual value the system uses to assign to files and processes associated with the new user.)
• Specify group ID manually—As with the user ID, check this box to set a specific group ID or just use the default of the next available group ID number. Likewise, specifying a group ID risks duplication.

Select OK to add the user to the system. An entry for the new user account is added to the /etc/passwd file and the new group account to the /etc/group file. I describe those later in this chapter. To modify user information later, or set different information, double-click on the user account you want to change. A User Properties window appears, like the one shown in Figure 11.2.

Figure 11.2 Modify existing user accounts from the User Properties window.

Most of the information you set before can be changed from the User Data tab. However, select the Account Info if you want the account to expire on a particular date or to lock the password so, temporarily, no one can log in as the user. On the Password Info tab, you can set when a password expires so you can force users to change their passwords after a set length of time. The Groups tab enables you to select check boxes to let a user belong to different groups.

Everything described with the User Manager window can be done from the command line as well. The next part of this chapter describes how to add user accounts from the command line with useradd or change them with the usermod command.

Adding users with useradd

Sometimes a Linux system won't have a desktop available to use the User Manager window. Other times, you might find it more convenient to add a lot of users at once with a shell script. For both cases, commands are available to enable you to add and modify user accounts from the command line.

The most straightforward method for creating a new user from the shell is the useradd command. After opening a Terminal window with root permission, you simply invoke useradd at the command prompt, with details of the new account as parameters.

The only required parameter is the login name of the user, but you probably want to include some additional information ahead of it. Each item of account information is preceded by a single-letter option code with a dash in front of it. The options available with useradd include the following:

• -c "comment here"—Provide a description of the new user account. Typically, this will be the person's full name. Replace comment with the name of the user account (-c Jake). Use quotes to enter multiple words (for example,-c "Jake Jackson").
• -d home_dir—Set the home directory to use for the account. The default is to name it the same as the login name and to place it in /home. Replace home_dir with the directory name to use (for example, -d /mnt/homes/jake).
• -D—Rather than create a new account, save the supplied information as the new default settings for any new accounts that are created.
• -e expire_date—Assign the expiration date for the account in YYYY-MM-DD format. Replace expire_date with a date you want to use. (For example, to expire an account on May 5, 2013, use -e 2013-05-05.)
• -f -1—Set the number of days after a password expires until the account is permanently disabled. The default, -1, disables the option. Setting this to 0 disables the account immediately after the password has expired. Replace -1 (that's minus one) with the number to use.
• -g group—Set the primary group (it must already exist in the /etc/group file) the new user will be in. Replace group with the group name (for example, -g wheel). Without this option, a new group is created that is the same as the user name and is used as that user's primary group.
• -G grouplist—Add the new user to the supplied comma-separated list of supplementary groups (for example, -G wheel,sales,tech,lunch). (If you use -G later with usermod, be sure to use -aG and not just -G. If you don't, existing supplementary groups are removed and the groups you provide here are the only ones assigned.)
• -k skel_dir—Set the skeleton directory containing initial configuration files and login scripts that should be copied to a new user's home directory. This parameter can be used only in conjunction with the -m option. Replace skel_dir with the directory name to use. (Without this option, the /etc/skel directory is used.)
• -m—Automatically create the user's home directory and copy the files in the skeleton directory (/etc/skel) to it. (This is the default action for Fedora and RHEL, so it's not required. It is not the default for Ubuntu.)
• -M—Do not create the new user's home directory, even if the default behavior is set to create it.
• -n—Turn off the default behavior of creating a new group that matches the name and user ID of the new user. This option is available with Fedora and RHEL systems. Other Linux systems often assign a new user to the group named users instead.
• -o—Use with -u uid to create a user account that has the same UID as another username. (This effectively lets you have two different usernames with authority over the same set of files and directories.)
• -p passwd—Enter a password for the account you are adding. This must be an encrypted password. Instead of adding an encrypted password here, you can simply use the passwd user command later to add a password for user. (To generate an encrypted MD5 password, type openssl passwd.)
• -s shell—Specify the command shell to use for this account. Replace shell with the command shell (for example, -s /bin/csh).
• -u user_id—Specify the user ID number for the account (for example, -u 793). Without the -u option, the default behavior is to automatically assign the next available number. Replace user_id with the ID number.

Let's create an account for a new user. The user's full name is Sara Green with a login name of sara. To begin, become root user and then type the following command:

# useradd -c "Sara Green" sara

Next, set the initial password for sara using the passwd command. You're prompted to type the password twice:

# passwd sara
Changing password for user sara.
New password: *******
Retype new password: *******

In creating the account for Sara, the useradd command performs several actions:

• Reads the /etc/login.defs and /etc/default/useradd files to get default values to use when creating accounts.
• Checks command-line parameters to find out which default values to override.
• Creates a new user entry in the /etc/passwd and /etc/shadow files based on the default values and command-line parameters.
• Creates any new group entries in the /etc/group file. (Fedora creates a group using the new user's name.)
• Creates a home directory, based on the user's name, in the /home directory.
• Copies any files located within the /etc/skel directory to the new home directory. This usually includes login and application startup scripts.

The preceding example uses only a few of the available useradd options. Most account settings are assigned using default values. You can set more values explicitly, if you want to. Here's an example that uses a few more options to do so:

# useradd -g users -G wheel,apache -s /bin/tcsh -c "Sara Green" sara

In this case, useradd is told to make users the primary group sara belongs to (-g), add her to the wheel and apache groups, and assign tcsh as her primary command shell (-s). A home directory in /home under the user's name (/home/sara) is created by default. This command line results in a line similar to the following being added to the /etc/passwd file:

sara:x:502:507:Sara Green:/home/sara:/bin/tcsh

Each line in the /etc/passwd file represents a single user account record. Each field is separated from the next by a colon (:) character. The field's position in the sequence determines what it is. As you can see, the login name is first. The password field contains an x because, in this example, the shadow password file is used to store encrypted password data (in /etc/shadow).

The user ID selected by useradd is 502. The primary group ID is 507, which corresponds to a private sara group in the /etc/group file. The comment field was correctly set to Sara Green, the home directory was automatically assigned as /home/sara, and the command shell was assigned as /bin/tcsh, exactly as specified with the useradd options.

By leaving out many of the options (as I did in the first useradd example), defaults are assigned in most cases. For example, by not using -g sales or -G wheel,apache, the group name mary was assigned to the new user. Some Linux systems (other than Fedora and RHEL) assign users as the group name by default. Likewise, excluding -s /bin/tcsh causes /bin/bash to be assigned as the default shell.

The /etc/group file holds information about the different groups on your Linux system and the users who belong to them. Groups are useful for enabling multiple users to share access to the same files while denying access to others. Here is the /etc/group entry created for sara:

sara:x:507:

Each line in the group file contains the name of a group, a group password (usually filled with an x), the group ID number associated with it, and a list of users in that group. By default, each user is added to his or her own group, beginning with the next available GID, starting with 500.

Setting user defaults

The useradd command determines the default values for new accounts by reading the /etc/login.defs and /etc/default/useradd files. You can modify those defaults by editing the files manually with a standard text editor. Although login.defs is different on different Linux systems, the following is an example containing many of the settings you might find in a login.defs file:

PASS_MAX_DAYS     99999
PASS_MIN_DAYS     0
PASS_MIN_LEN      5
PASS_WARN_AGE     7
UID_MIN                   500
UID_MAX                 60000
GID_MIN                   500
GID_MAX                 60000
CREATE_HOME yes

All uncommented lines contain keyword/value pairs. For example, the keyword PASS_MIN_LEN is followed by some whitespace and the value 5. This tells useradd that the user password must be at least five characters. Other lines enable you to customize the valid range of automatically assigned user ID numbers or group ID numbers. (Fedora starts at UID 500; earlier systems started with UID 100.) A comment section that explains that keyword's purpose precedes each keyword (which I edited out here to save space). Altering a default value is as simple as editing the value associated with a keyword and then saving the file before running the useradd command.

If you want to view other default settings, you can find them in the /etc/default/useradd file. Another way to see default settings is to type the useradd command with the -D option, as follows:

# useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel

You can also use the -D option to change defaults. When run with this flag, useradd refrains from actually creating a new user account; instead, it saves any additionally supplied options as the new default values in /etc/default/useradd. Not all useradd options can be used in conjunction with the -D option. You can use only the five options listed next.

• -b default_home—Set the default directory in which user home directories are created. Replace default_home with the directory name to use (for example, -b /garage). Usually, this is /home.
• -e default_expire_date—Set the default expiration date on which the user account is disabled. The default_expire_date value should be replaced with a date in the form YYYY-MM-DD (for example, -e 2011-10-15).
• -f default_inactive—Set the number of days after a password has expired before the account is disabled. Replace default_inactive with a number representing the number of days (for example, -f 7).
• -g default_group—Set the default group that new users will be placed in. Normally, useradd creates a new group with the same name and ID number as the user. Replace default_group with the group name to use (for example, -g bears).
• -s default_shell—Set the default shell for new users. Typically, this is /bin/bash. Replace default_shell with the full path to the shell that you want as the default for new users (for example, -s /bin/ash).

To set any of the defaults, give the -D option first, and then add the defaults you want to set. For example, to set the default home directory location to /home/everyone and the default shell to /bin/tcsh, type the following:

# useradd -D -b /home/everyone -s /bin/tcsh

In addition to setting up user defaults, an administrator can create default files that are copied to each user's home directory for use. These files can include login scripts and shell configuration files (such as .bashrc).

Other commands that are useful for working with user accounts include usermod (to modify settings for an existing account) and userdel (to delete an existing user account).

Modifying users with usermod

The usermod command provides a simple and straightforward method for changing account parameters. Many of the options available with it mirror those found in useradd. The options that can be used with this command include the following:

• -c username—Change the description associated with the user account. Replace username with the name of the user account (-c jake). Use quotes to enter multiple words (for example, -c "Jake Jackson").
• -d home_dir—Change the home directory to use for the account. The default is to name it the same as the login name and to place it in /home. Replace home_dir with the directory name to use (for example, -d /mnt/homes/jake).
• -e expire_date—Assign a new expiration date for the account in YYYY-MM-DD format. Replace expire_date with a date you want to use. (For October 15, 2013, use -e 2013-10-15.)
• -f -1—Change the number of days after a password expires until the account is permanently disabled. The default, -1, disables the option. Setting this to 0 disables the account immediately after the password has expired. Replace -1 with the number to use.
• -g group—Change the primary group (as listed in the /etc/group file) the user will be in. Replace group with the group name (for example, -g wheel).
• -G grouplist—Set the user's secondary groups to the supplied comma-separated list of groups. If the user is already in at least one group besides the user's private group, you must add the -a option as well (-Ga). If not, the user will belong to only the new set of groups and lose membership to any previous groups.
• -l login_name—Change the login name of the account.
• -L—Lock the account by putting an exclamation point at the beginning of the encrypted password in /etc/shadow. This locks the account, while still allowing you to leave the password intact (the -U option unlocks it).
• -m—Available only when –d is used, this causes the contents of the user's home directory to be copied to the new directory.
• -o—Use only with -u uid to remove the restriction that UIDs must be unique.
• -s shell—Specify a different command shell to use for this account. Replace shell with the command shell (for example, -s bash).
• -u user_id—Change the user ID number for the account. Replace user_id with the ID number (for example, -u 474).
• -U—Unlocks the user account (by removing the exclamation mark at the beginning of the encrypted password).

The following are examples of the usermod command:

# usermod -s /bin/csh chris
# usermod -Ga sales,marketing, chris

The first example changes the shell to the csh shell for the user named chris. In the second example, supplementary groups are added for the user chris. The -a option (-Ga) makes sure that the supplementary groups are added to any existing groups for the user chris. If the -a is not used, existing supplementary groups for chris are erased and the new list of groups includes the only supplementary groups assigned to that user.

Deleting users with userdel

Just as usermod is used to modify user settings and useradd is used to create users, userdel is used to remove users. The following command removes the user chris:

# userdel -r chris

Here, the user chris is removed from the /etc/password file. The –r option removes the user's home directory as well. If you choose not to use –r, as follows, the home directory for chris is not removed:

# userdel chris

Keep in mind that simply removing the user account does not change anything about the files that user leaves around the system (except those that are deleted when you use -r). However, ownership of files left behind appears as belonging to the previous owner's user ID number when you run ls -l on the files.

Before you delete the user, you may want to run a find command to find all files that would be left behind by the user. After you delete the user, you could search on user ID to find files left behind. Here are two find commands to do those things:

# find / -user chris -ls
# find / -uid 504 -ls

Because files that are not assigned to any username are considered to be a security risk, it is a good idea to find those files and assign them to a real user account. Here's an example of a find command that finds all files in the file system that are not associated with any user (the files are listed by UID):

# find / -nouser -ls 

Understanding Group Accounts

Group accounts are useful if you want to share a set of files with multiple users. You can create a group and change the set of files to be associated with that group. The root user can assign users to that group so they can have access to files based on that group's permission. Consider the following file and directory:

$ ls -ld /var/salesdocs /var/salesdocs/file.txt
drwxrwxr-x. 2 root sales 4096 Jan 14 09:32 /var/salesstuff/
-rw-rw-r--. 1 root sales    0 Jan 14 09:32 /var/salesstuff/file.txt

Looking at permissions on the directory /var/salesdocs (rwxrwxr-x), you see the second set of rwx shows that any member of the group (sales) has permission to read files in that directory (r is read), create and delete files from that directory (w is write), and change to that directory (x is execute). The file named file.txt can be read and changed by members of the sales group (based on the second rw-).

Using group accounts

Every user is assigned to a primary group. In Fedora and RHEL, by default, that group is a new group with the same name as the user. So if the user were named sara, the group assigned to her would also be sara. The primary group is indicated by the number in the third field of each entry in the /etc/passwd file, for example, the group ID 507 here:

sara:x:502:507:Sara Green:/home/sara:/bin/tcsh

That entry points to an entry in the /etc/group file:

sara:x:507:

Let's turn to the sara user and group accounts for examples. Here are a few facts about using groups:

• When sara creates a file or directory, by default, that file or directory is assigned to sara's primary group (also called sara).
• The user sara can belong to zero or more supplementary groups. If sara were a member of groups named sales and marketing, those entries could look like the following in the /etc/group file:

 sales:x:302:joe,bill,sally,sara
 marketing:x:303:mike,terry,sara

• The user sara can't add herself to a supplementary group. She can't even add another user to her sara group. Only someone with root privilege can assign users to groups.
• Any file assigned to the sales or marketing group will be accessible to sara with group and other permissions (whichever provides the most access). If sara wants to create a file with the sales or marketing groups assigned to it, she could use the newgrp command. In this example, sara uses the newgrp command to have sales become her primary group temporarily and creates a file:

 [sara]$ touch file1
 [sara]$ newgrp sales
 [sara]$ touch file2
 [sara]$ ls -l file*
 -rw-rw-r--. 1 sara sara  0 Jan 18 22:22 file1
 -rw-rw-r--. 1 sara sales 0 Jan 18 22:23 file2
 [sara]$ exit

It is also possible to allow users to temporarily become a member of a group with the newgrp command without actually being a member of that group. To do that, someone with root permission can use gpasswd to set a group password (such as gpasswd sales). After that, any user can type newgrp sales into a shell and temporarily use sales as their primary group by simply entering the group password when prompted.

Creating group accounts

As the root user, you can create new groups from the User Manager window or from the command line with the groupadd command. Also, as noted earlier, groups are created automatically when a user account is created.

Group ID numbers from 0 through 499 are assigned to special administrative groups. For example, the root group is associated with GID 0. Regular groups begin at 500 for Red Hat Enterprise Linux and Fedora. On the first UNIX systems, GIDs went from 0 to 99. Other Linux systems reserve GIDs between 0 to 1,000 for administrative groups.

Here are some examples of creating a group account with the groupadd command:

# groupadd kings
# groupadd -g 325 jokers

In the examples just shown, the group named kings is created with the next available group ID. After that, the group jokers is created using the 325 group ID. Some administrators like using an undefined group number under 500 so the group they create doesn't intrude on the group designations above 500 (so UID and GID numbers can go along in parallel).

To change a group later, use the groupmod command. For example:

# groupmod -g 330 jokers
# groupmod -n jacks jokers

In the first example, the group ID for jokers is changed to 330. In the second, the name jokers is changed to jacks. If you wanted to then assign any of the groups as supplementary groups to a user, you can use the usermod command (as described earlier in this chapter).

Managing Users in the Enterprise

The basic Linux method of handling user and group accounts has not changed since the first UNIX systems were developed decades ago. However, as Linux systems have become used in more complex ways, features for managing users, groups, and the permissions associated with them have been added on to the basic user/group model so that it could be:

• More flexible—In the basic model, only one user and one group can be assigned to each file. Also, regular users have no ability to assign specific permissions to different users or groups and very little flexibility setting up collaborative files/directories. Enhancements to this model allow regular users to set up special collaborative directories (using features such as sticky bit and set GID bit directories). Using Access Control Lists (ACLs), any user can also assign specific permissions to files and directories to any users and groups they like.
• More centralized—When you have only one computer, storing user information for all users in the /etc/password file is probably not a hardship. However, if you need to authenticate the same set of users across thousands of Linux systems, centralizing that information can save a lot of time and heartache. Red Hat Enterprise Linux includes features that enable you to authenticate users from LDAP servers or Microsoft Active Directories servers.

The following sections describe how to use features such as Access Control Lists (ACLs) and shared directories (sticky bit and set GID bit directories) to provide powerful ways to selectively share files and directories. Next, I describe how to manage user accounts from centralized authentication servers using the Authentication Configuration window.

Setting permissions with Access Control Lists

The Access Control List (ACL) feature was created so that regular users could share their files and directories selectively with other users and groups. With ACLs, a user can allow others to read, write, and execute files and directories without leaving those file system elements wide open or requiring the root user to change the user or group assigned to them.

Here are a few things to know about ACLs:

• For ACLs to be used, they must be enabled on a file system when that file system is mounted.
• In Fedora and Red Hat Enterprise Linux, ACLs are automatically enabled on any file system created when the system is installed.
• If you create a file system after installation (such as when you add a hard disk), you need to make sure that the acl mount option is used when the file system is mounted (more on that later).
• To add ACLs to a file, you use the setfacl command; to view ACLs set on a file, you use the getfacl command.
• To set ACLs on any file or directory, you must be the actual owner (user) assigned to it. In other words, being assigned user or group permissions with setfacl does not give you permission to change ACLs on those files yourself.
• Because multiple users and groups can be assigned to a file/directory, the actual permission a user has is based on a union of all user/group designations to which they belong. For example, if a file had read-only permission (r--) for the sales group and read/write/execute (rwx) for the market group, and mary belonged to both, mary would have rwx permission.

Setting ACLs with setfacl

Using the setfacl command, you can modify permissions (-m) or remove ACL permissions (-x). The following is an example of the syntax of the setfacl command:

setfacl -m u:username:rwx filename

In the example just shown, the modify option (-m) is followed by the letter u, indicating that you are setting ACL permissions for a user. After a colon (:), you indicate the username, followed by another colon and the permissions you want to assign. As with the chmod command, you can assign read (r), write (w), and/or execute (x) permissions to the user or group (in the example, full rwx permission is given). The last argument is replaced by the actual filename you are modifying.

The following are some examples of the user mary using the setfacl command to add permission for other users and groups on a file:

[mary]$ touch /tmp/memo.txt
[mary]$ ls -l /tmp/memo.txt 
-rw-rw-r--. 1 mary mary 0 Jan 21 09:27 /tmp/memo.txt
[mary]$ setfacl -m u:bill:rw /tmp/memo.txt
[mary]$ setfacl -m g:sales:rw /tmp/memo.txt

In the preceding example, mary created a file named /tmp/memo.txt. Using the setfacl command, she modified (-m) permissions for the user named bill so that he now has read/write (rw) permissions to that file. Then she modified permissions for the group sales so anyone belonging to that group would also have read/write permissions. Look at ls -l and getfacl output on that file now:

[mary]$ ls -l /tmp/memo.txt
-rw-rw-r--+ 1 mary mary 0 Jan 21 09:27 /tmp/memo.txt
[mary]$ getfacl /tmp/memo.txt 
# file: tmp/memo.txt
# owner: mary
# group: mary
user::rw-
user:bill:rw-
group::rw-
group:sales:rw-
mask::rw-
other::r--

From the ls -l output, notice the plus sign (+) in the rw-rw-r--+ output. The plus sign indicates that ACLs are set on the file, so you know to run the getfacl command to see how ACLs are set. The output shows mary as owner and group (same as what you see with ls -l), the regular user permissions (rw-), and permissions for ACL user bill (rw-). The same is true for group permissions and permissions for the group sales. Other permissions are r--.

The mask line (near the end of the previous getfacl example) requires some special discussion. As soon as you set ACLs on a file, the regular group permission on the file sets a mask of the maximum permission an ACL user or group can have on a file. So, even if you provide an individual with more ACL permissions than the group permissions will allow, the individual's effective permissions will not exceed the group permissions. For example:

]

 [mary]$ chmod 644 /tmp/memo.txt
[mary]$ getfacl /tmp/memo.txt
# file: tmp/memo.txt
# owner: mary
# group: mary
user::rw-
user:bill:rw-   #effective:r--
group::rw-      #effective:r--
group:sales:rw- #effective:r--
mask::r--
other::r--

Notice in the preceding example that even though the user bill and group sales have rw- permissions, their effective permissions are r--. So, bill or anyone in sales would not be able to change the file unless mary were to open permissions again (for example, by typing chmod 664 /tmp/memo.txt).

Setting default ACLs

Setting default ACLs on a directory enables your ACLs to be inherited. That means that when new files and directories are created in that directory, they are assigned the same ACLs. To set a user or group ACL permission as the default, you add a d: to the user or group designation. Consider the following example:

 [mary]$ mkdir /tmp/mary
[mary]$ setfacl -m d:g:market:rwx /tmp/mary/
[mary]$ getfacl /tmp/mary/
# file: tmp/mary/
# owner: mary
# group: mary
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:sales:rwx
default:group:market:rwx
default:mask::rwx
default:other::r-x

To make sure that the default ACL worked, create a subdirectory. Then run getfacl again. You will see that default lines are added for user, group, mask, and other, which are inherited from the directory's ACLs.

 [mary]$ mkdir /tmp/mary/test
[mary]$ getfacl /tmp/mary/test
# file: tmp/mary/test
# owner: mary
# group: mary
user::rwx
group::rwx
group:sales:rwx
group:market:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:group:sales:rwx
default:group:market:rwx
default:mask::rwx
default:other::r-x

Notice that when you create a file in that directory, the inherited permissions are different. Because a regular file is created without execute permission, the effective permission is reduced to rw-:

[mary@cnegus ∼]$ touch /tmp/mary/file.txt
[mary@cnegus ∼]$ getfacl /tmp/mary/file.txt
# file: tmp/mary/file.txt
# owner: mary
# group: mary
user::rw-
group::rwx         #effective:rw-
group:sales:rwx    #effective:rw-
group:market:rwx   #effective:rw-
mask::rw-
other::r--

Enabling ACLs

Basic Linux file systems have only one user and one group assigned to each file and directory and do not include ACL support by default. Linux ext file system types (ext2, ext3, and ext4) can add ACL support through a mount option. To add ACL support, you must add the acl mount option when you mount it. You can do that in any of several ways:

• Add the acl option to the fifth field in the line in the /etc/fstab file that automatically mounts the file system when the system boots up.
• Implant the acl line in the Default mount options field in the file system's super block, so that the acl option is used whether the file system is mounted automatically or manually.
• Add the acl option to the mount command line when you mount the file system manually with the mount command.

Keep in mind that in Fedora and Red Hat Enterprise Linux systems, you only have to add the acl mount option to those file systems you create after Linux is installed. The anaconda installer automatically adds ACL support to every file system it creates during install time. To check that the acl option has been added to a file system, determine the device name associated with the file system, and then run the tune2fs -l command to view the implanted mount options. For example:

# mount | grep home
/dev/mapper/mybox-home on /home type ext4 (rw)
# tune2fs -l /dev/mapper/mybox-home | grep "mount options"
Default mount options:    user_xattr acl

First, I typed the mount command to see a list of all file systems that are currently mounted, limiting the output by grepping for the word home (because I was looking for the file system mounted on /home). Once I saw the file system's device name, I used it as an option to tune2fs -l to find the default mount options line. There, I could see that mount options user_xattr (for extended attributes such as SELinux) and acl were both implanted in the file system super block so they would be used when the file system was mounted.

If the Default mount options field is blank (such as when you have just created a new file system), you can add the acl mount option using the tune2fs -o command. For example, I created a file system on a removable USB drive that was assigned as the /dev/sdc1 device. To implant the acl mount option and check that it is there, I ran the following commands:

# tune2fs -o acl /dev/sdc1
# tune2fs -l /dev/sdc1 | grep "mount options"
Default mount options:    acl

You can test that this worked by remounting the file system and trying to use the setfacl command on a file in that file system.

A second way to add acl support to a file system is to add the acl option to the line in the /etc/fstab file that automatically mounts the file system at boot time. The following is an example of what a line would look like that mounts the ext4 file system located on the /dev/sdc1 device to the /var/stuff directory:

/dev/sdc1     /var/stuff      ext4    acl        1 2

Instead of the defaults entry in the fourth field, I added acl. If there were already options set in that field, add a comma after the last option and add acl. The next time the file system is mounted, ACLs are enabled. If the file system were already mounted, I could type the following mount command as root to remount the file system, using acl or any other values added to the /etc/fstab file:

# mount -o remount /dev/sdc1

A third way you can add ACL support to a file system is to mount the file system by hand and specifically request the acl mount option. So, if there were no entry for the file system in the /etc/fstab file, after creating the mount point (/var/stuff), type the following command to mount the file system and include ACL support:

# mount -o acl /dev/sdc1 /var/stuff

Keep in mind that the mount command only mounts the file system temporarily. When the system reboots, the file system will not be mounted again, unless you add an entry to the /etc/fstab file.

Adding directories for users to collaborate

There is a special set of three permission bits that are typically ignored when you use the chmod command to change permissions on the file system. These bits can set special permissions on commands and directories. The focus of this section is setting the bits that help you create directories to use for collaboration.

As with read, write, and execute bits for user, group, and other, these special file permission bits can be set with the chmod command. If, for example, you run chmod 775 /mnt/xyz, the implied permission is actually 0775. To change permissions, you can replace the number 0 with any combination of those three bits (4, 2, and 1), or you can use letter values instead. (Refer to Chapter 4, “Moving Around the Filesystem,” if you need to be reminded about how permisisons work.) The letters and numbers are shown in Table 11.1.

Table 11.1 Commands to Create and Use Files

The bits you are interested in for creating collaborative directories are the set group ID bit (2) and sticky bit (1). If you are interested in other uses of the set user ID and set group ID bits, refer to the sidebar “Using Set UID and Set GID Bit Commands.”

Creating group collaboration directories (set GID bit)

By creating a set GID directory, any files created in that directory are assigned to the group assigned to the directory itself. The idea is to have a directory where all members of a group can share files but still protect them from other users. Here's a set of steps for creating a collaborative directory for all users in the group I created called sales:

# groupadd -g 301 sales

# usermod -aG sales mary

# mkdir /mnt/salestools

$ ls /bin/su
-rwsr-xr-x. 1 root root  30092 Jan 30 07:11 su

# chgrp sales /mnt/salestools

# chmod 2775 /mnt/salestools

 # su - mary
 [mary]$ touch /mnt/salestools/test.txt
 [mary]$ ls -ld /mnt/salestools/ /mnt/salestools/test.txt
 drwxrwsr-x. 2 root sales 4096 Jan 22 14:32 /mnt/salestools/
 -rw-rw-r--. 1 mary sales    0 Jan 22 14:32 /mnt/salestools/test.txt

Typically, a file created by mary would have the group mary assigned to it. But because test.txt was created in a set group ID bit directory, the file is assigned to the sales group. Now, anyone that belongs to the sales group can read or write that file, based on group permissions.

Creating restricted deletion directories (sticky bit)

A restricted deletion directory is created by turning on a directory's sticky bit. What makes a restricted deletion directory different than other directories? Normally, if write permission is open to a user on a file or directory, that user is able to delete that file or directory. However, in a restricted deletion directory, unless you are the root user or the owner of the directory, you can never delete another user's files.

Typically, a restricted deletion directory is used as a place where lots of different users can create files. For example, the /tmp directory is a restricted deletion directory:

$ ls -ld /tmp
drwxrwxrwt. 116 root root 36864 Jan 22 14:18 /tmp

You can see the permissions are wide open, but instead of an x for the execute bit for other, the t indicates that the sticky bit is set. The following is an example of creating a restricted deletion directory with a file that is wide open for writing by anyone:

[mary]$ mkdir /tmp/mystuff
[mary]$ chmod 1777 /tmp/mystuff
[mary]$ cp /etc/services /tmp/mystuff/
[mary]$ chmod 666 /tmp/mystuff/services
[mary]$ ls -ld /tmp/mystuff /tmp/mystuff/services
drwxrwxrwt. 2 mary mary   4096 Jan 22 15:28 /tmp/mystuff/
-rw-rw-rw-. 1 mary mary 640999 Jan 22 15:28 /tmp/mystuff/services

With permissions set to 1777 on the /tmp/mystuff directory, you can see that all permissions are wide open, but a t appears instead of the last execute bit. With the /tmp/mystuff/services file open for writing, any user could open it and change its contents. However, because the file is in a sticky bit directory, only root and mary can delete that file.

Centralizing User Accounts

Although the default way of authenticating users in Linux is to check user information against the /etc/passwd file and passwords from the /etc/shadow file, there are other ways to do authentication as well. In most large enterprises, user account information is stored in a centralized authentication server, so each time you install a new Linux system, instead of adding user accounts to that system, you have the Linux system query the authentication server when someone tries to log in.

As with local passwd/shadow authentication, configuring centralized authentication requires that you provide two types of information: account information (username, user/group IDs, home directory, default shell, and so on) and authentication method (different types of encrypted passwords, smart cards, retinal scans, and so on). Linux provides ways of configuring those types of information.

Because I hope you will someday use your Linux skills to work in a large Linux installation, I want to introduce the concept of centralized authentication. For now, I will just discuss how to connect to existing authentication servers (rather than set up those servers themselves) and have users of a Linux system you configure authenticate against those types of servers.

Using the Authentication Configuration window

In Fedora and Red Hat Enterprise Linux, there is a graphical window for configuring centralized authentication called the Authentication Configuration window. Through that window, you can configure where your system gets account information and what type of authentication method is used to verify users. Supported centralized database types include:

• LDAP—The Lightweight Directory Access Protocol (LDAP) is a popular protocol for providing directory services (such as phone books, addresses, and user accounts). It is an open standard that is configured in many types of computing environments.
• NIS—The Network Information Service (NIS) was originally created by Sun Microsystems to propagate information such as user accounts, host configuration, and other types of system information across many UNIX systems. Because NIS passes information in clear text, most enterprises now use the more secure LDAP or Winbind protocols for centralized authentication.
• Winbind—Selecting Winbind from the Authentication Configuration window enables you to authenticate your users against a Microsoft Active Directory (AD) server. Many large companies extend their desktop authentication setup to do server configuration as well as using an AD server.

For this introduction to configuring centralized authentication servers, you will configure a Linux system to authenticate against an LDAP server, using the Authentication Configuration window in Red Hat Enterprise Linux.

To begin, you need to gather information about the LDAP service at your location. That includes information about the account database and the authentication method:

• LDAP Search Base DN—This is the distinguished name of the LDAP database used to identify the location of the user account records. Often, the name is constructed from the company's DNS domain name. For example, dc=example,dc=com.
• LDAP server—The host name of the LDAP server. For example, ldap://ldap.example.com.
• Use TLS to encrypt connections—With this selected, you must also select to identify the location of a certificate authority (CA) certificate that will be downloaded to the local system to use to validate and encrypt communications with the LDAP server. Transport Layer Security (TLS) certificates for an organization are obtained from certificate authorities such as Verisign. Or you could create self-signed certificates.
• Authentication method—Instead of using regular MD5 passwords, pick either LDAP password or Kerberos as the authentication method with LDAP. For Kerberos, you must also provide information about the Kerberos server, which includes the Kerberos Realm, KDCs, and Admin Servers. All this information should be provided by the administrators who manage your company's Kerberos servers.

To start the Authentication Configuration window from a Red Hat Enterprise Linux 6 desktop, select System ⇒ Administration ⇒ Authentication. For a default system that only does local (passwd/shadow) authentication, the window appears.

To add LDAP authentication, select the User Account Database box and select LDAP. Then fill in the information described in the preceding bullet points.

If the new authentication method is configured properly, you should be able to go to a shell and validate that. If you know of a user account available from the LDAP server, use the following getent command to check that the account is available:

# getent passwd jsmith
jsmith:x:13599:13600:John Smith:/home/jsmith:/bin/bash

If you see the account information, then you know your system was able to retrieve it from the LDAP server. The next thing to check is that the authentication method is working as well. For that, you could try to log in as the user from the console or by using the ssh command. For example:

$ ssh jsmith@localhost

When prompted, enter the username and password. If it succeeds, you know that both the account and authentication information you entered for your LDAP server were correct.

With your authentication centralized, consider centralizing your users' home directories as well. Using the Linux automounter (autofs service), you could set up home directories that are automatically mounted when each user logs in, regardless of which machine they are logging into. (See Chapter 20, “Configuring an NFS File Server,” for information on setting up an NFS server and configuring clients to automount from that server.)

Summary

Having separate user accounts is the primary method of setting secure boundaries between the people who use your Linux system. Regular users typically can control the files and directories within their own home directories, but very little outside of those directories.

In this chapter, you learned how to add user and group accounts, how to modify them, and even how to extend user and group accounts beyond the boundaries of the local /etc/password file. You also learned that authentication can be done by accessing centralized LDAP servers.

The next chapter introduces another basic topic needed by Linux system administrators: how to manage disks. In that chapter, you learn how to partition disks, add filesystems, and mount them, so the contents of the disk partitions are accessible to those using your system.

Exercises

Use these exercises to test your knowledge of adding and managing user and group accounts in Linux. These tasks assume you are running a Fedora or Red Hat Enterprise Linux system (although some tasks will work on other Linux systems as well). If you are stuck, solutions to the tasks are shown in Appendix B (although in Linux, there are often multiple ways to complete a task).