Unix Group Administration

'adm' group like whell group and sysadm group on solaris can be used to allow to read logfiles without having to su.

Every UNIX user belongs to one or more groups. Like user accounts, groups have both a groupname and a group identification number (GID). GID values are also historically 16-bit integers.

As the name implies, UNIX groups are used to group users together. As with usernames, groupnames and numbers are assigned by the system administrator when each user's account is created. Groups can be used by the system administrator to designate sets of users who are allowed to read, write, and/or execute specific files, directories, or devices.

Each user belongs to a primary group that is stored in the /etc/passwd file. The GID of the user's primary group follows the user's UID. Consider, again, our /etc/passwd example:

rachel:eH5/.mj7NB3dx:181:100:Rachel Cohen:/u/rachel:/bin/ksh

In this example, Rachel's primary GID is 100.

Groups provide a handy mechanism for treating a number of users in a certain way. For example, you might want to set up a group for a team of students working on a project so that students in the group, but nobody else, can read and modify the team's files.

Groups can also be used to restrict access to sensitive information or specially licensed applications to a particular set of users: for example, many UNIX computers are set up so that only users who belong to the kmem group can examine the operating system's kernel memory. The ingres group is commonly used to allow only registered users to execute the commercial Ingres database program. And a sources group might be limited to people who have signed nondisclosure forms so as to be able to view the source code for some software.

NOTE: Some special versions of UNIX support MAC (Mandatory Access Controls), which have controls based on data labeling instead of, or in addition to, the traditional UNIX DAC (Discretionary Access Controls). MAC-based systems do not use traditional UNIX groups. Instead, the GID values and the /etc/group file may be used to specify security access control labeling or to point to capability lists. If you are using one of these systems, you should consult the vendor documentation to ascertain what the actual format and use of these values might be.

The /etc/group file

The /etc/group file contains the database that lists every group on your computer and its corresponding GID. Its format is similar to the format used by the /etc/passwd file.[3]

[3] As with the password file, if your site is running NIS, NIS+, NetInfo, or DCE, the /etc/group file may be incomplete or missing. See the discussion in "The /etc/passwd File and Network Databases" in Chapter 3.

Here is a sample /etc/group file that defines five groups: wheel, uucp, vision, startrek, and users:

wheel:*:0:root,rachel
uucp:*:10:uucp
users:*:100:
vision:*:101:keith,arlin,janice
startrek:*:102:janice,karen,arlin

The first line of this file defines the wheel group. The fields are explained in Table 4.1.

Most versions of UNIX use the wheel group[4] as the list of all of the computer's system administrators. Not all versions of UNIX call this group wheel; this is group 0, regardless of what it is named.

The second line of this file defines the uucp group. The only member in the uucp group is the uucp user. The third line defines the users group; the users group does not explicitly list any users; each user on this particular system is a member of the users group by virtue of their individual entries in the /etc/passwd file.

The remaining two lines define two groups of users. The vision group includes the users keith, arlin and janice. The startrek group contains the users janice, karen, and arlin. Notice that the order in which the usernames are listed on each line is not important. (This group is depicted graphically in Figure 4.1.)

Remember, the users mentioned in the /etc/group file are in these groups in addition to the groups mentioned as their primary groups in the file /etc/passwd. For example, Rachel is in the users group even though she does not appear in that group in the file /etc/group because her primary group number is 100. On some versions of UNIX, you can issue the groups command or the id command to list which groups you are currently in.

Groups are handled differently by versions of System V UNIX before Release 4 and by Berkeley UNIX; SVR4 incorporates the semantics of BSD groups.

NOTE: It is not necessary for there to be an entry in the /etc/group file for a group to exist! As with UIDs and account names, UNIX actually uses only the integer part of the GID for all settings and permissions. The name in the /etc/group file is simply a convenience for the users - a means of associating a mnemonic with the GID value.

Figure 4.1 illustrates how users can be included in multiple groups.

Figure 4.1: Users and groups

4.1.3.2 Groups and older AT&T UNIX

Under versions of AT&T UNIX before SVR4, a user can occupy only a single group at a time. To change your current group, you must use the newgrp command. The newgrp command takes a single argument: the name of the group that you're attempting to change into. If the newgrp command succeeds, it execs a shell that has a different GID, but the same UID:

$ newgrp news
$

This is similar to the su command used to change UID.

Usually, you'll want to change into only these groups in which you're already a member; that is, groups that have your username mentioned on their line in the /etc/group file. However, the newgrp command also allows you to change into a group of which you're not normally a member. For this purpose, UNIX uses the group password field of the /etc/group file. If you try to change into a group of which you're not a member, the newgrp command will prompt you for that group's password. If the password you type agrees with the password for the group stored in the /etc/group file, the newgrp command temporarily puts you into the group by spawning a subshell with that group:

$ newgrp fiction 
password: rates34 
$

You're now free to exercise all of the rights and privileges of the fiction group.

The password in the /etc/group file is interpreted exactly like the passwords in the /etc/passwd file, including salts (described in Chapter 8, Defending Your Accounts). However, most systems do not have a program to install or change the passwords in this file. To set a group password, you must first assign it to a user with the passwd command, then use a text editor to copy the encrypted password out of the /etc/passwd file and into the /etc/group file. Alternatively, you can encode the password using the /usr/lib/makekey program (if present) and edit the result into the /etc/group file in the appropriate place.[5]

[5] We suspect that passwords have seldom been used in the group file. Otherwise, by now someone would have developed an easier, one-step method of updating the passwords. UNIX gurus tend to write tools for anything they have to do more than twice and that require more than a few simple steps. Updating passwords in the group file is an obvious candidate, but a corresponding tool has not been developed. Ergo, the operation must not be common.

NOTE: Some versions of UNIX, such as AIX, do not support group passwords.

4.1.3.3 Groups and BSD or SVR4 UNIX

One of the many enhancements that the Berkeley group made to the UNIX operating system was to allow users to reside in more than one group at a time. When a user logs in to a Berkeley UNIX system, the program /bin/login scans the entire /etc/group file and places the user into all of the groups in which that user is listed.[6] The user is also placed in the primary group listed in the user's /etc/passwd file entry. When the system needs to determine access rights to something based on the user's membership in a group, it checks all the current groups for the user to determine if that access should be granted (or denied).

[6] If you are on a system that uses NIS, NIS+ or some other system for managing user accounts throughout a network, these network databases will be referenced as well. For more information, see Chapter 19, RPC, NIS, NIS+, and Kerberos.

Thus, Berkeley and SVR4 UNIX have no obvious need for the newgrp command - indeed, many of the versions do not include it. However, there may be a need for it in some cases. If you have a group entry with no users listed but a valid password field, you might want to have some users run the newgrp program to enter that group. This action will be logged in the audit files, and can be used for accounting or activity tracking. However, situations where you might want to use this are likely to be rare. Note, however, that some systems, including AIX, do not support use of a password in the /etc/group file, although they may allow use of the newgrp command to change primary group.

Fields in the group File

The fields in the group file are separated by colons and contain the following information:

group-name:group-password:gid:user-list

For example:

bin::2:root,bin,daemon

The following table describes the group file fields.

Table 4–14 Fields in the group File

Default group file

The default Solaris group file contains the following system groups that support some system-wide task, such as printing, network administration, and electronic mail. Many of these having corresponding entries in the passwd file.

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,tty,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
smmsp::25:smmsp
sysadmin::14:root
nobody::60001:
noaccess::60002:
nogroup::65534:

Table 4–15 Default group File Entries

Solaris 9 User Account Administration

This sample chapter covers the administration of user and group accounts, the system files used to store the user and group account information, and the initialization files associated with user accounts.

• User accounts
• Group accounts
• admintool
• Initialization files
• The system profile

Concepts You Need to Master

• Creating and deleting user accounts
• Administering passwords
• Creating and deleting group accounts
• Initialization files and templates

Account Administration

User and group accounts control access to the system. The administration of user accounts and group accounts along with the passwords associated with these accounts is a key system administration activity.

User Accounts

User accounts can be added, modified, or deleted using command-line utilities or by using the admintool(1M) command. Use of the admintool command reduces or eliminates the possible introduction of typos and other errors that might affect all the user accounts.

However, the admintool command requires a graphical interface and is more time consuming than using the command-line utilities manually. These command-line utilities are as follows:

• useradd(1M)
• usermod(1M)
• userdel(1M)

Both the admintool command and the command-line utilities are described in this chapter.

Creating an Account Using the admintool Command

When the admintool command is started, the Users window is displayed. To display the Add User window, select Add from the Edit pull-down menu. The Add User window, consists of three sections: User Identity, Account Security, and Home Directory.

The User Identity section provides the information that needs to be defined to add a user account. All this information is stored in the /etc/passwd file, except secondary groups information, which is stored in the /etc/group file. Table 3.1 lists the fields of the User Identity section.

Table 3.1 User identity Fields of the admintool: Add User Window

The Account Security section provides the information used to determine how the password should be defined and to set up password aging. All this information is stored in the /etc/shadow file. Table 3.2 lists the fields of the Account Security section.

Table 3.2 Account Security Fields of the admintool: Add User Window

The Home Directory section is used to define the home directory of the account and to create it if necessary. This path is stored in the /etc/passwd file. The appropriate initialization files are created in the home directory based on the type of login shell selected.

Modifying an Account Using the admintool Command

To modify a user account, start the admintool command if it is not already active. Display the Users window by selecting Users from the Browse pull-down menu.

Click the desired account entry and then select Modify from the Edit pull-down menu. The Modify User window is displayed. Change the fields as appropriate and click Apply to save the changes.

Deleting an Account Using the admintool Command

To delete a user account, start the admintool command if it is not already active. Display the Users window.

Click the desired account and then select Delete from the Edit pull-down menu. In the Warning window, select Delete to delete the user account.

CAUTION

Because using the admintool command makes creating, modifying, and deleting user accounts very easy and intuitive, Exam 310-014 concentrates on using the useradd, usermod, and userdel commands for administering user accounts.

Creating an Account Using the useradd Command

The useradd(1M) command provides a quick method to add a new user account. At a minimum, the account name must be specified as a command-line argument. Table 3.3 lists the command-line arguments supported by the useradd command.

Table 3.3 Command-Line Arguments for the useradd Command

The following example shows how to create a user account using the useradd command:

# useradd -d /export/home/user1 -m -g other -u 1050 user1
6 blocks
# 

This command creates the user1 user account, assigns it UID 1050, makes it a member of group other and creates its home directory /export/home/user1.

To make life a little easier, the useradd command also supports the -D command-line argument, which allows default values to be assigned to authorizations (-A), base directory (-b), group (-g), expiration date (-e), maximum inactivity (-f), execution profile (-P), and role (-R). Subsequent uses of the useradd command will use these default values if they are not specified. For example, the following command can be used to assign a default base directory and default group. Whenever defaults are assigned or changed, the new defaults are listed:

# useradd -D -b /export/home -g other

group=other,1 project=,3 basedir=/export/home 
skel=/etc/skel shell=/bin/sh inactive=0 
expire= auths= profiles= roles= 
#
# useradd -m -u 1051 user2
6 blocks
# 

Because a default base and group were defined, the user2 account is a member of the other group and has a home directory of /export/home/user2.

NOTE

User accounts created with the useradd command do not have a password. These accounts are locked and cannot be used until a password is set for the account using the passwd(1) command.

Modifying an Account Using the usermod Command

The usermod(1M) command is used to modify an existing user account. The command-line arguments are identical to the useradd command-line arguments with the following exceptions:

• The base directory (-b) is not available. Use -d to specify a new directory. Don't forget to include the -m if the directory doesn't exist.
• The set default (-D) is not available.
• The template directory (-k) is not available.
• A new user account name is specified using -l account if the account name is being modified.

Keep in mind that if the account name is changed, the name of the home directory does not change unless the -d and -m command-line arguments are used. The following example shows the usermod command changing the name of the user1 account to user3.

# ls -l
total 22
drwx------  2 root   root    8192 Jan 13 21:05 lost+found
drwxr-x---  2 user3  other    512 Mar 31 13:23 user1
drwxr-x---  2 user2  other    512 Mar 31 13:45 user2
#
# usermod -luser3 -d /export/home/user3 -m user1
6 blocks
#
# ls -l
total 22
drwx------  2 root   root    8192 Jan 13 21:05 lost+found
drwxr-x---  2 user2  other    512 Mar 31 13:45 user2
drwxr-x---  2 user3  other    512 Mar 31 13:23 user3
# 

Deleting an Account Using the userdel Command

The userdel(1M) command is used to delete a user account. The user account is specified as a command-line argument. Only one other command-line argument is supported. This is -r, which is used to remove the home directory. The following shows deleting the user3 account:

# userdel -r user3
# 

Group Accounts

Group accounts can be added, modified, or deleted using command-line utilities or by using the admintool(1M) command. Use of the admintool command reduces or eliminates the possible introduction of typos and other errors that might affect all the group accounts.

However, the admintool command requires a graphical interface and is more time consuming than using the command-line utilities manually. These command-line utilities are as follows:

• groupadd(1M)
• groupmod(1M)
• groupdel(1M)

Both the admintool command and the command-line utilities are described in the following sections.

Creating a Group Using the admintool Command

To create a group account, start the admintool command if it is not already active. Display the Groups window by selecting Groups from the Browse pull-down menu.

Then, display the Add Group window by selecting Add from the Edit pull-down menu.

Enter a unique group name in the Group Name field. Use the next available GID number or enter a unique GID in the Group ID field. In the Members List field, enter one or more user account names separated by commas. Using the mouse, click OK. The new group is displayed in the Groups window.

Modifying a Group Using the admintool Command

To modify a group account, display the Group window. Click the account you want to modify, and then select Modify from the Edit menu. Change the fields in the Modify Group window, and click Apply to save the changes.

Deleting a Group Using the admintool Command

To delete a group account, display the Groups window, and then select the account you want to delete. Select Delete from the Edit menu. A Warning window displays that lists the group. Click Delete.

CAUTION

Because using the admintool command makes creating, modifying, and deleting group accounts very easy and intuitive, Exam 310-014 concentrates on using the groupadd, groupmod, and groupdel commands for administering group accounts.

Creating a Group Using the groupadd Command

The groupadd(1M) command provides a quick method to add a new group account. At a minimum, the group account name must be specified as a command-line argument. The groupadd command supports two other command-line arguments. The first is -g gid, which used to specify the unique GID associated that should be associated with group. It must be a decimal integer. If GID is not specified, the next highest available GID is assigned. The other command-line argument is -o, which allows a duplicate GID to be assigned to the group.

The following example shows creating a group using the groupadd command.

# 
# groupadd -g 1000 newgroup
# 

Modifying a Group Using the groupmod Command

The groupmod(1M) command is used to modify an existing group account. The command-line arguments are identical to the groupadd command-line arguments, except the new group account name is specified using -n name if the group account name is being modified. The following example shows how to use the groupmod to change group newgroup to ngroup.

# groupmod -n ngroup newgroup
#

Deleting a Group Using the groupdel Command

The groupdel(1M) command is used to delete a group account. The group account is specified as a command-line argument.

# groupdel ngroup
# 

Password Administration

Password administration involves setting parameters to control password aging, changing a user's password as needed, and possibly locking a user account to prevent use.

Password Aging

The parameters of the /etc/shadow file determine the password aging policy. These are set through the Account Security fields of the admintool command's Add or Modify User Account window. This includes how long a password is valid (Max Change), how often it can be changed (Min Change), and how long an account can be inactive before the password must be changed (Max Inactive). These parameters enforce a policy for protecting the integrity of passwords.

Note that of these three password-aging parameters, only Max Inactive can be specified using the useradd command and modified using the usermod command.

Password Requirements

Unless specified by a superuser account such as root, passwords must meet the following requirements:

• A password must contain at least the number of characters specified by the PASSLENGTH parameter contained in the /etc/default/passwd file. The default is six. It is best to increase this value to eight.
• A password must contain at least two alphabetic characters and at least one numeric character (within the first PASSLENGTH characters).
• A password cannot be the same as user account name, the reverse of the user account name, or a circular shift of the user account name. Any uppercase letters are mapped to lowercase letters for requirement checking. This means that the password for the guest user account cannot be guest, tseug, uestg, estgu, GUEST, and so on.
• ‰A new password must be different by at least three characters from the old password. Once again, uppercase and lowercase letters are equivalent for requirement checking.

CAUTION

Passwords can be any length, but only the first eight characters are significant. For example, a password can be defined as 25administration but 25admini is actually used to log into the system.

Keep in mind that these requirements do not apply when root or some other superuser account defines its own password or the password of another user account.

Changing Passwords Using the admintool Command

To change the password of a user account, start the admintool command if it is not already active. Display the Users window by selecting Users from the Browse pull-down menu.

The user account can be selected in two ways: by double-clicking the account entry or by clicking the account entry to highlight it and then selecting Modify from the Edit pull-down menu. Using either method, the Modify User window is displayed.

To modify the account password, position the mouse cursor over the Password field and hold down the left button. Then, move the mouse cursor over the Normal Password item and release the mouse button.

Enter the same password for both the Enter Password and the Verify Password fields. Asterisks are displayed in place of each character entered. Using the mouse, click OK. To save the password, click OK in the Modify User window.

Changing Passwords using the passwd Command

Other than using the admintool command, the passwd(1) command is the only other way to change the password for a user account. When used without any command-line arguments, the passwd command changes the password of the current user account. The following code shows how to change the password for the currently logged in user (dla):

$ passwd
passwd: Changing password for dla
Enter login password: 
New password: 
Re-enter new password: 
passwd (SYSTEM): passwd successfully changed for dla
$

Note that the current password must be entered before a new password can be specified. When a superuser account, such as root, uses the passwd command, the current password is not required.

A variety of command-line arguments are provided to support changing passwords. Table 3.4 lists the more significant command-line arguments.

Table 3.4 Selected Command-Line Arguments for the passwd Command

A superuser account can change the password for another user account. The user account is specified as a command-line argument. The following shows the superuser changing the password for the dla account:

# passwd dla
New password: 
Re-enter new password: 
passwd (SYSTEM): passwd successfully changed for dla
# 

Locking a User Account Using the admintool Command

An account can be locked to prevent it from being used. In the admintool's Users window, select the account you want to lock. Select Modify from the Edit menu. In the Modify User window, choose the Account Is Locked item, save the change, and click OK.

Administrative System Files

Three administrative system files are used to define and manage user and group accounts:

• /etc/passwd
• /etc/shadow
• /etc/group

/etc/passwd

The /etc/passwd file is an ASCII file that is used to define user accounts on the local system. Each line represents a user account and consists of seven colon-delimited fields. Table 3.5 lists the fields of an entry in the /etc/passwd file.

Table 3.5 /etc/passwd Fields

The following listing shows the default contents of a Solaris 9 /etc/password file:

root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
nobody:x:60001:60001:Nobody:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x Nobody:/:

/etc/shadow

The /etc/shadow file is an ASCII file that is used to store passwords for local user accounts along with any password restrictions or aging. Access is restricted to superusers to protect the passwords. Each line represents the password of a user account and consists of nine colon-delimited fields. Table 3.6 lists the fields of an entry in the /etc/shadow file.

The /etc/shadow file should always be protected from unauthorized access or copying because it contains all user passwords for the system. Although the passwords are stored in encrypted form, it is still possible to find passwords using specialized software.

Table 3.6 /etc/shadow Fields

The following listing shows the guest entry from a Solaris 9 /etc/shadow file that uses all the fields except flag:

guest:on7GbE18yYAek:10688:5:30:5:20:10844:

/etc/group

The /etc/group file is an ASCII file that is used to store information about groups on the local system. Each line represents a group and consists of four colon-delimited fields. Table 3.7 lists the fields of an entry in the /etc/group file.

Table 3.7 /etc/group Fields

The following listing shows the default contents of a Solaris 9 /etc/group file:

root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:
smmsp::25:smmsp
nobody::60001:
noaccess::60002:
nogroup::65534:

User Account Initialization Files

Several initialization (or startup) files are associated with each user account home directory. These files are used to specify commands to be executed when the associated event occurs. Depending on the login shell being used (Bourne Shell, C Shell, or Korn Shell), there might be a login initialization file, a shell startup file, or a logout file. Table 3.8 lists the various initialization files.

Table 3.8 Initialization Files

Commands in the login initialization file are executed when the user logs in. All three common shells provide a login initialization file. Commands in the shell startup file are executed whenever the logged-in user starts a shell. Both csh and ksh provide this capability. The ENV parameter is used to define the name of the ksh shell startup initialization file. Only csh provides a file for automatic execution of commands when a user logs out.

CAUTION

It is important to know the names of the initialization files and their uses, not only for the Bourne shell, but also the C and Korn shells.

The System Profile

For user accounts that use sh (Bourne shell) or ksh as a login shell, commands in the system profile are executed before the user's login initialization file. This file is named /etc/profile and, when executed, sets a default terminal type (TERM) and then calls umask(1) to set the default file permission mask to 022. If the user's home directory does not include a file by the name of .hushlogin, the user's storage quota is displayed using quot(1M), the message of the day (if any) is displayed, and a notification message is displayed if new email has arrived for the user.

The following listing shows the default contents of /etc/profile for a Solaris 9 system:

#ident "@(#)profile  1.19  01/03/13 SMI"  /* SVr4.0 1.3  */
# The profile that all logins get before using their own .profile.

trap "" 2 3
export LOGNAME PATH
if [ "$TERM" = "" ]
then
    if /bin/i386
    then
        TERM=sun-color
    else
        TERM=sun
    fi
    export TERM
fi
#    Login and -su shells get /etc/profile services.
#    -rsh is given its environment in its .profile.
case "$0" in
-sh | -ksh | -jsh | -bash)
    if [ ! -f .hushlogin ]
    then
        /usr/sbin/quota
        #    Allow the user to break the Message-Of-The-Day only.
        trap "trap '' 2" 2
        /bin/cat -s /etc/motd
        trap "" 2
        /bin/mail -E
        case $? in
        0)
            echo "You have new mail."
            ;;
        2)
            echo "You have mail."
            ;;
        esac
    fi
esac
umask 022
trap 2 3

Initialization File Templates

When a user account is created and a home directory specified, part of setting up the user account is to copy the appropriate default initialization files to the user's home directory. These initial files or templates are stored in the /etc/skel directory.

For user accounts that use sh or ksh as the login shell, the /etc/skel/local.profile file is copied to the .profile file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.profile file:

# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# ident "@(#)local.profile   1.10  01/06/23 SMI"
stty istrip
PATH=/usr/bin:/usr/ucb:/etc:.
export PATH
#

For user accounts that use csh as the login shell, the /etc/skel/local.login file is copied to the .login file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.login file:

# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# ident "@(#)local.login    1.7   01/06/23 SMI"
stty -istrip
# setenv TERM ´tset -Q -´

In addition, for user accounts that use csh as the login shell, the /etc/skel/local.cshrc file is copied to the .cshrc file in the user's home directory. The following listing shows the default contents of the /etc/skel/local.cshrc file:

#ident "@(#)local.cshrc    1.2   00/05/01 SMI"
umask 022
set path=(/bin /usr/bin /usr/ucb /etc .)
if ( $?prompt ) then
    set history=32
endif

Also in the /etc/skel directory is a simple .profile that can also be used as a default:

#    This is the default standard profile provided to a user.
#    They are expected to edit it to meet their own needs.

MAIL=/usr/mail/${LOGNAME:?}

When an account is created using the admintool command, the appropriate /etc/skel file is copied to the home directory of the user account based on the selected login shell (that is, .profile for Bourne and Korn shells, .cshrc for C shell, and so on). However when the useradd command is used, all the /etc/skel files (.profile, local.cshrc, local.login, and local.profile) are copied to the home directory regardless of the selected shell. In this case, the appropriate file(s) (based on type of shell) must be manually configured.

Customizing the User Environment

The initialization file templates can be modified to provide a custom environment for new user accounts. In addition, the system profile (/etc/profile) can be modified to customize the environment for all users during login initialization.

CAUTION

Keep in mind that the system profile, /etc/profile, is executed before the user's profile. This provides the ability to control and restrict the user environment before the user has an opportunity to make any modifications.

To customize individual user accounts, the initialization files in the user's home directories can be modified. For the most part, this will consist of adding commands to be automatically executed or defining shell parameters.

Defining Shell Variables in .profile

Variables defined and exported in the .profile become part of the user's environment. These variables are available to programs and shells executed by the user.

A common shell variable defined in the .profile is LPDEST, which is used to specify a default printer. To define HPLaser as the default printer, include the following in the .profile for a user account:

LPDEST=HPLaser
export LPDEST

An alternative way is to specify both commands on the same line and separate the commands with a semicolon, as shown in the following:

LPDEST=HPLaser; export LPDEST

A similar syntax can be used for a user account that uses the Korn shell as a login shell. ksh also supports the following variation:

export LPDEST=HPLaser

Although defining variables for csh user accounts is not a certification requirement, the syntax for two csh methods of defining variables is shown in the following listing:

set LPDEST=HPlaser
setenv LPDEST HPlaser

NOTE

Changes made to the user's login initialization file do not take effect until the user logs in again, or until the .profile is executed by preceding it with a dot separated by a space. This executes the .profile and makes it part of the current environment.

Sourcing .profile

For user accounts that use the Solaris Common Desktop Environment (CDE), the /usr/dt/bin/Xsession command that starts the desktop can be configured to read and process the .login (csh) or .profile (sh and ksh) login initialization file in the user's home directory as part of the startup process.

The first user-specific file that Xsession calls is the .dtprofile file, located in the user's home directory. The last line of the default .dtprofile file is as follows:

DTSOURCEPROFILE=true

This will cause the .login or .profile file to be executed (or sourced) automatically. To change this default behavior and prevent the login initialization file from being sourced, change true to false.

Summary

User accounts are created using admintool or the useradd commands. Account information is stored in the /etc/passwd file. The /etc/shadow file is used to store user account passwords.

Groups are created using admintool or the groupadd commands. Group information and passwords are stored in the /etc/group file.

Initialization files are associated with each type of shell (Bourne, C, and Korn). These initialization files can be used to set up the environment before the user has access to the system, when each shell is created, or when the user exits the system. Initialization file templates are available in /etc/skel to provide a starting point for creating custom initialization files. The system profile (/etc/profile) is executed before any user account initialization files.

Exam Prep Practice Questions

Question 1

Where are the user account initialization file templates stored?

1. Under the user account home directories
2. In the /etc/skel directory
3. In the /usr/skel directory
4. In the /skel directory

The correct answer is B. Answer A is incorrect because the user's copy of the templates (not the templates themselves) are stored under the home directories. The directories in answers C and D do not exist.

Question 2

Which of the following are valid settings for the admintool command password field? [Select all that apply.]

1. Normal password
2. Account is locked
3. Cleared until first login
4. No password—setuid only
5. One-time password

The correct answers are A, B, C, and D. Solaris 9 does not provide a one-time password capability. Therefore, answer E is incorrect.

Question 3

Enter the command used to add a user-defined Bourne shell variable to the user environment so that other programs can use the variable.

The only correct answer is export.

Question 4

Which of the following command-line arguments can be specified when using the useradd or usermod commands? [Select all that apply.]

1. u uid
2. g gid
3. d home_directory
4. l account

The correct answers are A, B, and C. The UID, GID, and home directory can be defined using the specified useradd command-line arguments and modified using the same usermod command-line arguments. Answer D is incorrect because the -l command-line argument is only used with the usermod command to specify a new account name. The account name for the useradd command does not use the -l command-line argument.

Question 5

Which command can be used to change the members (that is, the user accounts) assigned to an existing group?

1. usermod
2. groupmod
3. groupadd
4. groupmem

The correct answer is A. The usermod command is used once for each user account that is to be added or deleted from a group. Answer B, the groupmod command, and answer C, the groupadd command, do not affect group membership. Answer D, the groupmem command, does not exist.

Question 6

Enter the full pathname of the system profile.

The correct answer is /etc/profile.

Question 7

What is the -P command-line argument of the useradd command used to specify?

1. Account password
2. Execution profile
3. Initialization file (profile) template
4. Primary group

The correct answer is B, the execution profile. Answer A is incorrect because a password cannot be specified using the useradd command. All accounts created using the useradd are locked until a password is defined using the passwd or admintool commands. Answer C is incorrect because a template cannot be specified. However a profile template directory can be specified using the -k command-line argument. Answer D is incorrect, because the primary group is specified by the -g command-line argument.

Question 8

When used with the usermod command, what effect does the -o command-line option have?

1. The existing user information is overwritten.
2. A duplicate UID can be specified.
3. The information about the specified user is displayed.
4. A duplicate GID can be specified.
5. The user account is deleted.

The correct answer is B. None of the other answers is supported by the usermod command.

Question 9

When using the admintool command to create a user account, which of the following can be specified as the login shell? [Select all that apply.]

1. Bourne (/bin/sh)
2. C (/bin/csh)
3. Korn (/bin/ksh)
4. Other (specify path)

All the answers are correct.

Question 10

Which commands can be used by root to change a password? [Select all that apply.]

1. admintool
2. passmgmt
3. usermod
4. passwd

The correct answers are A and D. The passmgmt and usermod commands (answers B and C) do not provide any facility to specify a password.

Question 11

Enter the name of the system used to store user account passwords.

The correct answer is /etc/shadow.

Need to Know More?

Mulligan, John P., Solaris 8 Essential Reference, (New Riders, Indianapolis, IN, 2001).

Sobell, Mark G., A Practical Guide to Solaris (Addison-Wesley, Reading, MA, 1999).

Sun Microsystems, System Administration Guide: Basic Administration. Available in printed form on the Web at docs.sun.com and from the online documentation provided with the Solaris 9 operating system.

Sun Microsystems, System Reference Manual, Section 1—User Commands. Available in printed form, on the Web at docs.sun.com and from the online documentation provided with the Solaris 9 operating system.

Sun Microsystems, System Reference Manual, Section 1M—System Administration Commands. Available in printed form, on the Web at docs.sun.com, and from the online documentation provided with the Solaris 9 operating system.

Sun Microsystems, System Reference Manual, Section 4—File Formats, is available in printed form, on the Web at docs.sun.com, and from the online documentation provided with the Solaris 9 operating system.

Old News

dirgroup

dirgroup is a Perl script for merging the contents of a directory, /etc/group.d, into the file /etc/group. Storing group information in a directory allows users other than root to own and manage Unix groups. This minor change to Unix permission semantics provides many of the advantages of much more complex ACL systems.

Securing Debian HOWTO Chapter 8 Frequently asked Questions

8.1 Is Debian more secure than X?

A system is as secure as its administrator is capable of making it.

8.2 Is there are hardening program for Debian?

Yes. Bastille Linux, originally oriented towards some Linux distributions (RedHat and Mandrake) currently works for Debian. Steps are being taken to integrate the changes made to the upstream version, in any case the package in Debian is, of course, name bastille.

Some people believe, however, that a hardening tool does not eliminate the need for good administration.

8.3 How can I make service XYZ more secure?

You will find information in this document to make some services (FTP, Bind) more secure in Debian GNU/Linux. For services not covered here, however, check the program's documentation, or general Linux information. Most of the security guidelines for Unix systems apply also to Debian so securing service X in Debian is, most of the time, like securing the service for any other Linux distribution (or Unix, for that matter).

---

8.4 Questions regarding users and groups

8.5 Are all system users necessary?

Yes and no. Debian comes with some predefined users (id < 99 as described in Debian Policy) for some services so that installing new services is easy (they are already run by the appropriate user). If you do not intend to install new services, you can safely remove those users who do not own any files in your system and do not run any services.

You can easily find users not owning any files by executing the following command (be sure to run it as root, since a common user might not have enough permissions to go through some sensitive directories):

     cut -f 1 -d : /etc/passwd |
     while read i; do find / -user "$i" | grep -q . && echo "$i"; done

These users are provided by base-passwd. You will find in its documentation more information on how these users are handled in Debian.

The list of default users (with a corresponding group) follows:

• root: Root is (typically) the superuser.

• daemon: Some unprivileged daemons that need to be able to write to some files on disk run as daemon.daemon (portmap, atd, probably others). Daemons that don't need to own any files can run as nobody.nogroup instead, and more complex or security conscious daemons run as dedicated users. The daemon user is also handy for locally installed daemons, probably.

• bin: maintained for historic reasons.

• sys: same as with bin. However, /dev/vcs* and /var/spool/cups are owned by group sys.

• sync: The shell of user sync is /bin/sync. Thus, if its password is set to something easy to guess (such as ""), anyone can sync the system at the console even if they have no account on the system.

• games: Many games are sgid to games so they can write their high score files. This is explained in policy.

• man: The man program (sometimes) runs as user man, so it can write cat pages to /var/cache/man

• lp: Used by printer daemons.

• mail: Mailboxes in /var/mail are owned by group mail, as is explained in policy. The user and group is used for other purposes as well by various MTA's.

• news: Various news servers and other associated programs (such as suck) use user and group news in various ways. Files in the news spool are often owned by user and group news. Programs such as inews that can be used to post news are typically sgid news.

• uucp: The uucp user and group is used by the UUCP subsystem. It owns spool and configuration files. Users in the uucp group may run uucico.

• proxy: Like daemon, this user and group is used by some daemons (specifically, proxy daemons) that don't have dedicated user id's and that need to own files. For example, group proxy is used by pdnsd, and squid runs as user proxy.

• majordom: Majordomo has a statically allocated uid on Debian systems for historical reasons. It is not installed on new systems.

• postgres: Postgresql databases are owned by this user and group. All files in /var/lib/postgresql are owned by this user to enforce proper security.

• www-data: Some web browsers run as www-data. Web content should *not* be owned by this user, or a compromised web server would be able to rewrite a web site. Data written out by web servers, including log files, will be owned by www-data.

• backup: So backup/restore responsibilities can be locally delegated to someone without full root permissions.

• operator: Operator is historically (and practically) the only 'user' account that can login remotely, and doesn't depend on NIS/NFS.

• list: Mailing list archives and data are owned by this user and group. Some mailing list programs may run as this user as well.

• irc: Used by irc daemons. A statically allocated user is needed only because of a bug in ircd -- it setuid()s itself to a given UID on startup.

• gnats.

• nobody, nogroup: Daemons that need not own any files run as user nobody and group nogroup. Thus, no files on a system should be owned by this user or group.

Other groups which have no associated user:

• adm: Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

• tty: Tty devices are owned by this group. This is used by write and wall to enable them to write to other people's tty's.

• disk: Raw access to disks. Mostly equivalent to root access.

• kmem: /dev/kmem and similar files are readably by this group. This is mostly a BSD relic, but any programs that need direct read access to the system's memory can thus be made sgid kmem.

• dialout: Full and direct access to serial ports. Members of this group can reconfigure the modem, dial anywhere, etc.

• dip: THe group's man stands for "Dialup IP". Being in group dip allows you to use a tool such as ppp, dip, wvdial, etc. to dial up a connection. The users in this group cannot configure the modem, they can just run the programs that make use of it.

• fax: Allows members to use fax software to send / receive faxes.

• voice: Voicemail, useful for systems that use modems as answering machines.

• cdrom: This group can be used locally to give a set of users access to a cdrom drive.

• floppy: This group can be used locally to give a set of users access to a floppy drive.

• tape: This group can be used locally to give a set of users access to a tape drive.

• sudo: Members of this group do not need to type their password when using sudo. See /usr/share/doc/sudo/OPTIONS.

• audio: This group can be used locally to give a set of users access to an audio device.

• src: This group owns source code, including files in /usr/src. It can be used locally to give a user the ability to manage system source code.

• shadow: /etc/shadow is readable by this group. Some programs that need to be able to access the file are set gid shadow.

• utmp: This group can write to /var/run/utmp and similar files. Programs that need to be able to write to it are sgid utmp.

• video: This group can be used locally to give a set of users access to an video device.

• staff: Allows users to add local modifications to the system (/usr/local, /home) without needing root privileges. Compare with group "adm", which is more related to monitoring/security.

• users: While Debian systems use the user group system by default (each user has their own group), some prefer to use a more traditional group system. In that system, each user is a member of the 'users' group.

---

8.5.1 What is the difference between the adm and the staff group?

'adm' are administrators and is mostly useful to allow them to read logfiles without having to su.

'staff' is useful for more helpdesk/junior sysadmins type of people and gives them the ability to do things in /usr/local and create directories in /home.