9 Administering User Accounts and Groups

Adding, modifying, and removing individual user accounts and groups of users is a routine but important activity that a system administrator frequently performs.

After introducing user account and group administration, this chapter describes the following tasks:

Adding a user account

Changing information in a user account

Removing a user account

Adding and removing a group

Note

You can also use the SysMan dxaccounts command to perform these tasks.

9.1 Understanding User Accounts and Groups

Administering user accounts and groups involves managing the contents of the system's password and group files. On standalone systems, the files you manage are /etc/passwd, which is documented in passwd(1), and /etc/group, which is documented in group(4).

On networked systems, typically, the Network Information Service (NIS) is for central account and group management. NIS allows participating systems to share a common set of password and group files. See the Network Administration manual for more information.

If enhanced security is enabled on your system, you need to administer more than the /etc/passwd file for security. For example, the protected password database is used for security related information such as minimum password lengths and password expiration times. These tasks are documented in the Security manual.

9.1.1 The Password File

The passwd file for a standalone system identifies each user (including root) on your system. Each passwd file entry is a single line that contains seven fields. The fields are separated by colons and the last field ends with a new-line character. The syntax of each entry and the meaning of each field is as follows:

username:password:user_id:group_id:user_info:\
login_directory:login_shell

username: The name for the user account. The username must be unique and consist of from one to eight alphanumeric characters.
password: You cannot enter a password directly. Enter an asterisk (*) in the passwd field to disable a login to that account. An empty password field allows anyone who knows the login name to log in to your system as that user. Refer to Section 9.2.1.4 for instructions on assigning a user password with the passwd command.
user_id: The UID for this account. This is an integer with the limit determined by the value of maximum UIDs enabled on the system and must be unique for each user on the system. Refer to Section 9.1.4 for information on UID and GID values. Reserve the UID 0 for root. Assign each UID in ascending order beginning with 100. Lower numbers are used for pseudousers such as bin or daemon.
group_id: The GID for this account. This is an integer between 0 and 32767. Reserve the GID 0 for the system group. Be sure to define the GID in the group file.
user_info: This field contains additional user information such as the full user name, office address, telephone extension, and home phone. The finger command reads the information in the user_info field. Users can change the contents of their user_info field with the passwd command. Refer to Section 9.3.2, as well as the finger(1) and passwd(1) reference pages for more information.
login_directory: The absolute pathname of the directory where the user account is located immediately after login. The login program assigns this pathname to the HOME environment variable. Users can change the value of the HOME variable, but if a user changes the value, then the home directory and the login directory are two different directories. Create the login directory after adding a user account to the passwd file. Typically the user's name is used as the name of the login directory. Refer to the chown(1), mkdir(1), chmod(1), and chgrp(1) reference pages for additional information on creating a login directory.
login_shell: The absolute pathname of the program that starts after the user logs in. Normally, a shell starts. If you leave this field empty, the Bourne shell /bin/sh starts. Refer to the sh(1) reference page for information on the Bourne shell. Users can change their login shell by using the chsh command. Refer to Section 9.3.3 and the chsh(1) reference page for more information.

9.1.2 The Group File

All users are members of at least one group. The group file identifies the group name for a user. There are two primary reasons to group user accounts:

Several users work together on the same files and directories; grouping these users together simplifies file and directory access.

Only certain users are permitted access to system files or directories; grouping them together simplifies the identification of privileged users.

The group file is used for the following purposes:

To assign a name to a group identification number used in the passwd file

To allow users to be members of more than one group by adding the user account to the corresponding group entries

Each entry in the group file is a single line that contains four fields. The fields are separated by colons, and the last field ends with a new-line character. The syntax of each entry and the meaning of each field is as follows:

groupname: password: group_id: user1 [user2,...,userN]

groupname: The name of the group defined by this entry. The groupname consists of from one to eight alphanumeric characters and must be unique.
password: Place an asterisk (*) in this field. Entries for this field are currently ignored.
group_id: The group identification number (GID) for this group. This is an integer between 0 and 32767. Reserve the GID 0 for the system. The GID must be unique.
user: The user account belonging to this group as defined in the passwd file. If more than one user belongs to the group, the user accounts are separated by commas. The last user account ends with a new-line character. A user can be a member of more than one group.

There is a limitation on the number of groups that a user can be in, as documented in group(4). The maximum line length is LINE_MAX as defined in the limits.h file. Compaqrecommends that user accounts be divided into a number of manageable groups.

9.1.3 The Administrative Tools

There are several tools you use to administer user accounts and groups:

The Account Manager, which provides a graphical user interface for managing system envrironments with standard security or enhanced security features. The Account Manager can also manage the NIS account databases. For more information on using the Account Manager, please refer to the application's online help and the dxaccounts(1X) reference page.

Note

The Account Manager is the preferred graphical interface for managing user accounts and groups. It replaces the Xsysadmin and XIsso commands.

Several commands provide a command line interface to user account and group management, including user accounts on systems using NIS and enhanced security. The commands are documented in the following reference pages: useradd(8), usermod(8), userdel(8), groupadd(8), groupmod(8), and groupdel(8).

The adduser and addgroup utilities, documented in adduser(8) and addgroup(8). These utilities provide simple, interactive scripts you can use to add new user accounts and groups. These utilities can be used only on systems that do not use NIS.

The vipw utility, documented in vipw(8), allows you to invoke an editor in order to edit the password file manually. You can use the utility to edit the local password database, but you cannot use it to edit the NIS database. Additionally, you cannot use the vipw utility on systems that have enhanced security. The vipw command allows you to edit the passwd file and at the same time locks the file to prevent others from modifying it. This command also does consistency checks on the password entry for root and does not allow a corrupted root password to be entered into the passwd file.

9.1.4 UIDs and GIDs

Each user is known to the system by a unique number called a user identifier (UID). The system also knows each user group by a unique number called a group identifier (GID). The system uses these numbers to track user file access permissions and group privileges and to collect user accounting statistics and information.

The maximum number of UIDs and GIDs allowed is 2,147,483,647 (31 bits). This does not mean that 2.14 million users can simultaneously log onto a system; rather, it means that 2,147,483,647 user and group identifiers are available. The maximum number of users that can be logged on is determined by the available system resources. To preserve strict binary compatibility with legacy applications, the new limits are not enabled by default in this release.

9.1.4.1 Enabling or Disabling Extended UID and GID Support

By default, extended UIDs are not enabled in the kernel. To enable this feature, you use sysconfig or the dxkerneltuner interface to set the value of variable enable_extended_uids to 1 (enabled). Note that when extended UIDs and GIDs are disabled, files owned by a user with an extended UID or GID will be inaccessible to all users except root. Any user with an extended UID or GID will not have access to log in to the system or use the su command to access their accounts.

To enable or disable extended UID and GID support, do the following:

Become the root user (use the su command)

Use the sysconfig command to set the following attribute to the proc subsystem of the /etc/sysconfigtab file:
```
# enable_extended_uids=n
```
Where the value of n is 1 to enable and 0 to disable
Alternatively, you can use the dxkerneltuner graphical user interface to set this attribute. Refer to the dxkerneltuner(8) reference page, or see Section 5.2.1.2 for an example of its use.

Extended UID and GID support is now enabled or disabled as required.

9.1.4.2 Checking for Extended UID and GID Support

The following sample program demonstrates how to check the maximum number of UIDs supported by any version of the Tru64 UNIX operating system. The maximum number of GIDs will always be the same as the maximum number of UIDs:

#include #include #include  
 
#include  
 
#ifndef TBL_UIDINFO
#define TBL_UIDINFO 56
#endif
 
 
main()
{
     uid_t uid_max;
 
 
     errno = 0;
 
 
     uid_max = table (TBL_UIDINFO, 0, (char *)0, 1, 0);
 
 
     if ((errno != 0) && ((int)uid_max < 0))
          uid_max = UID_MAX;
 
 
     printf(%d\n", uid_max);
 
 
}

9.1.4.3 Applications Affected by Extended UIDs and GIDs

The following programs are affected by extended UID and GID support.

Clusters

Extended UID and GID support can be enabled in a TruCluster Available Server Software or TruCluster Production Server Software configuration only after all member systems have installed (or upgraded to) Version 1.5 of the appropriate TruCluster software product. To enable extended UID or GID support, set the enable_extended_uids parameter on every system as directed in this appendix and reboot every system. Do not use extended UIDs and GIDs on any member system until you have rebooted the last member system. Once you have enabled extended UID and GID support in a cluster, you must not disable it. Disabling this support will disrupt the operation of your cluster.

Kerberos

Kerberos Version 4 does not support extended UIDs and GIDs. If you use Kerberos Version 4 and need extended UID and GID support, you should upgrade to Kerberos Version 5.

System V File System

The System V file system (S5FS) does not support extended UIDs and GIDs. File system syscall that specifies UIDs and GIDs greater than 65,535 will return an EINVAL error. Users assigned a UID or GID greater than 65,535 will not be able to create or own files on a System V file system. Consider using the UFS, MFS, or AdvFS as a solution.

The ls Command

The ls -l command does not display the disk block usage on quota files or sparse files. This is not a result of the implementation of extended UIDs and GIDs, but rather a result of the behavior of the ls -l command. When extended UIDs and GIDs are enabled, quota files and sparse files may appear much larger than expected. To display the actual disk block usage for any file, use the ls -s command.

The cp Command

The cp command will incorrectly copy quota files or other sparse files. This is not a result of the implementation of extended UIDs and GIDs, but rather a result of the behavior of the cp command when it reads a file. When extended UIDs and GIDs are enabled, quota files and other sparse files may be copied to a new file that is much larger than expected. To correctly copy quota files or other sparse files, use the dd command with the conv=sparse parameter:

% dd conv=sparse if= inputfile  of= outputfile

The vdump/vrestore Utilities and UFS File Systems

If a UFS file system that contains quota files or other sparse files is backed up using the vdump utility and restored using the vrestore utility, the quota files or other sparse files will be restored as follows:

The first page of a file on disk will be restored as a fully populated page; that is, empty nonallocated disk blocks will be zero filled.

Any additional pages on disk will be restored sparse.

The dxarchiver Utility

The dxarchiver utility does not support extended UIDs and GIDs. However, the pax and tar utilities do support extended UIDs and GIDs and can be used as alternatives. If you need to use the dxarchiver utility, you must not enable extended UID or GID support.

The cpio Utility

The cpio utility does not support extended UIDs and GIDs. However, the pax and tar utilities do support extended UID and GIDs and can be used as alternatives. If you need to use the cpio utility, you must not enable extended UID or GID support.

The pax Utility

The pax utility, used to extract, list, or write archive files has been modified to support long file names and extended UID/GID values. To take advantage of these enhancements, specify the xtar format with the -x option.

The tar Utility

The tar utility, used to extract, list, or write archive files has been modified to support long file names and extended UID/GID values. To take advantage of these enhancements, specify the -E option when using the tar utility.

PATHWORKS

PATHWORKS does not support extended UIDs and GIDs. If you use PATHWORKS and need extended UID or GID support, you should upgrade to ASDU (Advancer Server for Tru64 UNIX) Version 4.0 or higher.

9.2 Adding a User Account

You can add a user to the system in three ways:

Add a user account with the adduser command utility. This utility supersedes the useradd interactive script and is a command-line equivalent to dxaccounts. Refer to the adduser(8) reference page for more information. adduser enables you to script repetitive account management tasks and to create a number of new accounts simultaneously.

Using the dxaccounts graphical user interface. Refer to the online help for information on using this interface.

While adduser and dxaccountsare the preferred tools for adding a user account, you can also do it manually by editing system files. This task is documented in the following section.

Note

There are limits on length of command lines that may affect commands such as useradd. The /usr/include/limits.h file limits LINE_MAX to 2048 characters. You must split command line entries into into multiple lines limited to 255 characters, or incorrect data may be added to the /etc/passwd file.

9.2.1 Adding a User Account Manually

To add a user account manually:

Add an entry for the user to the passwd file by using the vipw command.

Add an entry for the user account to the group file.

Supply the default shell scripts for the user's working environment.

Assign a password to protect the user account.

Verify the accuracy of the group and passwd files.

The following sections describe these tasks in detail.

9.2.1.1 Adding a User Account to the passwd File

Note

You cannot use the vipw utility to edit the protected password database on systems running with enhanced security. For these systems, you should use the adduser utility, the useradd command, or the Account Manager graphical interface to edit the passwd file.

To edit the passwd file:

Enter the vipw command to add the required line entry to the passwd file:
```
# vipw
root:TZVtfX5VbS3KY:0:1:System PRIVILEGED Account,,,:/:/bin/sh
daemon:*:1:daemon
uucp:*:2:uucp

.
.
.
marcy:*:201:20:Marcy Swanson,dev,x1234:/usr/users/marcy:/bin/sh
```
The previous example shows that user marcy has a UID of 201 and a GID of 20. The login directory is /usr/users/marcy and the Bourne shell (/bin/sh) is defined as the login shell. Since the password field contains an asterisk (*), user marcy cannot log in to the system. Section 9.2.1.4 describes how to add a password to the passwd file.

Close the file.

If a hashed passwd database exists, vipw uses the mkpasswd command to re-create it. A hashed passwd database is an indexed database that allows for faster searches of the passwd file. The following example shows the message displayed after closing the passwd file where a hashed passwd database existed previously:

10 password entries, maximum length 88

If a hashed passwd database does not exist, a message is displayed informing you that passwd it does not exist and asks if you want a database created. If you want a hashed passwd database, enter yes at the prompt. If you do not want a hashed passwd database, enter no at the prompt. Refer to vipw(8) for more information.

Note that when the /etc/passwd file is very large, a performance degradation may occur. If the number of passwd entries reaches the 30,000 to 80,000 range or greater, mkpasswd will sometimes fail to create a hashed (ndbm) database. Because the purpose of this database is to allow for efficient (fast) searches for password file information, failure to build it causes commands that rely on it to do a linear search of /etc/passwd. This results in a serious performance degradation for those commands.

If you use use the mkpasswd -s option to avoid this type of failure, a potential database or binary compatibility problem may arise. If an application that accesses the password database created by mkpasswd is built statically (nonshared), that application will be unable to read from or write to the password database correctly. This would cause the application to fail either by generating incorrect results or by possibly dumping core.

Any statically linked application would be affected if it directly or indirectly calls any of the libc ndbm routines documented in the ndbm(3) reference page and then accesses the password database. To remedy this situation, you must re-link the application. If the mkpasswd -s option is avoided, you will not see this compatibility problem.

Note

In an NIS environment you can add a user account to either the local passwd file or the NIS distributed passwd file. Accounts added to the local passwd file are visible only to the system to which they are added. Accounts added to the NIS distributed passwd file are visible to all NIS clients that have access to the distributed file. Refer to nis_manual_setup(7) for more information on adding users in a distributed environment.

9.2.1.2 Adding an Entry to the group File

To add a new group or a user to an existing group, add a line entry to the group file, as follows:

Use the cp command to copy the group file to a temporary file. For example, enter:
```
# cp group group.sav
```

Open the group file and add the required line entry. Be sure to include all four fields in this entry. A file is displayed similar to the following, which shows that users diaz, kalle, marcy, and chris belong to the users group that has a GID of 15:
```
system:*:0:root,diaz,kalle,marcy
daemon:*:1:daemon
uucp:*:2:uucp

.
.
.
users:*:15:diaz,kalle,marcy,chris
```

Close the file.

Use the vipw command to edit the passwd file to include the GID in the group_id field of each user who is a member of the group. Refer to Section 9.2.1.1 for more information about the passwd file.

If at a later date you change the group a user belongs to, be sure to change the parent directory's GID also.

9.2.1.3 Providing the Default Shell Scripts

Users can customize their working environment by modifying their startup files. When a user logs in to the system, the login shell looks for startup files in the login directory. If the shell finds a startup file, it reads the file and executes the commands.

Table 9-1 displays each shell and the corresponding startup files.

Table 9-1: Shells and Their Startup Files

Shell	System Startup File	Login Startup Files
`/bin/csh`	`/etc/csh.login`	`.cshrc`, `.login`
`/bin/ksh`	`/etc/profile`	`.profile`
`/bin/sh`	`/etc/profile`	`.profile`

The operating system uses these startup files to initialize local and global environment variables, shell variables, and terminal types. Use the following procedure to copy the startup files to the login directory of each user account:

Copy the startup files for each shell to the user's login directory by using the cp command. For example, to copy the startup files to the user marcy directory, enter:
```
# cd /usr/skel
# cp -R `ls -A` /usr/users/marcy
```

Change to the user's login directory and change file ownership and access permissions from root to the user for each file. For example, to make these changes to all of the files beginning with dot (.), for user marcy, enter the following sequence of commands:
```
# cd /usr/users/marcy
# chmod 755 .??*
# chown marcy .??*
```

To confirm that the changes were made, use the ls command to list marcy's files:
```
# ls -Al
```

Refer to the csh(1), ksh(1), and the sh(1) reference pages for more information on the shell commands.

9.2.1.4 Assigning a Password

Use the passwd command to assign a password for a user account. When you enter the passwd command, the program prompts you for a password. Each password must have at least five characters, but not more than eight, and can include digits, symbols, and the characters of your alphabet. The password cannot be all lowercase characters. The passwd command encrypts the specified password and inserts it in the password field of the passwd file.

To assign an initial password, use the following syntax:

passwd username

For example, to assign an initial password for user marcy, enter the following command:


# passwd marcy

The system responds with the following prompts. Enter and verify the new password for the user. To ensure confidentiality, the password will not be displayed.

Changing password for marcy.
 
New password:
Please don't use an all-lower case password.
Unusual capitalization, control characters or digits are suggested.
New password:
Retype new password:

If a hashed passwd database is not in use, the system displays the following informational message:

Hashed database not in use, only /etc/passwd text file updated.

A hashed passwd database is an indexed database that allows for a faster search of the passwd file.

9.2.1.5 Verifying the Accuracy of the group and passwd Files

Once you have completed all the tasks for adding a user account, use the grpck and the pwck commands to check the accuracy of the group and passwd files.

Note

If your system is running enhanced security, you should also use the authchk utility to verify the accuracy of the protected password database.

The grpck command verifies that the number of fields, group name, GID, and all login names that appear in the passwd file are correct. If any fields are incorrect, grpck writes the inconsistencies to standard output. For example:


# grpck
users:*:15:diaz,kalle,marcy,chris,farkle
        farkle - Logname not found in password file     [1]
mem:*:3:
        Null login name     [2]
+:
        Too many/few fields     [3]

Refer to Section 9.2.1.1 for information on adding a user account to the passwd file. [Return to example]

Ignore this message. [Return to example]

Ignore this message. These characters are necessary for running NIS. [Return to example]

Refer to the grpck(8) reference page for more information.

The pwck command checks for any inconsistencies in the passwd file. The pwck command verifies the number of fields, login name, UID, GID, existence of a login directory, and optional program name. If any of the fields are missing, pwck writes the inconsistencies to standard output. For example:


# pwck
nobody:*Nologin:4294967294:4294967294:anonymous NFS user:/:
        Invalid UID     [1]
        Invalid GID     [2]
        Optional shell file not found     [3]

Refer to Section 9.1.4 for valid UID numbers. [Return to example]

Refer to Section 9.1.4 for valid GID numbers. [Return to example]

Ignore this message. [Return to example]

Refer to the pwck(8) reference page for more information.

9.3 Changing Information in a User Account

This section describes how to change information about a user account. The following tasks are discussed:

Changing passwords

Changing the user_info field

Changing the login shell

Setting disk quotas

9.3.1 Changing Passwords

You should periodically change the root password. This protects the system from access by system users who should not have root access, as well as from external intruders.

There may be times when a user forgets his or her password. If this happens, change the user's password as described in Section 9.2.1.4 and tell the user the new password.

9.3.2 Changing the user_info Field

The user_info field in the passwd file contains the name, room number, office phone, and home phone of the user. To change this information, use the chfn command with the following syntax:

chfn [username]

For example, to change the information for user marcy, enter:

% chfn marcy

The system displays information similar to the following example. The brackets ([ ]) indicate a default response. Press Return to accept the defaults or enter a different response and press Return.

Default values are printed inside of '[]'.
To accept the default, type <return>.
To have a blank entry, type the word 'none'.
 
Name [Marcy Swanson]: [Return]
Room number (Exs: 597E or 197C) []: [Return]
Office Phone (Ex: 6426000) []: 3311
Home Phone (Ex: 9875432) []: [Return]

9.3.3 Changing the Login Shell

There may be a time when you want to change a user's login shell. To see a list of the shells the user is allowed to select from, enter the following command:

# cat /etc/shells

The system prints a list similar to the following:

/bin/sh
/bin/csh
/bin/ksh

To change a user's login shell, use the chsh command with the following syntax:

chsh [username]

For example, to change user marcy's login shell from the Bourne shell to the C shell, enter:


# chsh marcy

The system responds with the following information. At the prompt, enter the new shell user marcy will be using. For example:

Old shell: /bin/sh
New shell: /bin/csh

The next time user marcy logs in, she will be using the /bin/csh shell.

9.3.4 Setting File System Quotas

If you configured your system with file system quotas (also called disk quotas), you can set a quota for the number of inodes or disk blocks allowed for each user account or group on your system. To optimize disk space and to save yourself some work, set quotas by grouping user accounts according to their need for disk space. The following information is specific to the UNIX File System (UFS). If you are using the Advanced File System (AdvFS), refer to the AdvFS Administrationguide.

9.3.4.1 Understanding User Account and Group Quota Limits

You set quotas for user accounts and groups by file system. For example, a user account can be a member of several groups on a file system and also a member of other groups on other file systems. The file system quota for a user account is for a user account's files on that file system. A user account's quota is exceeded when the number of blocks (or inodes) used on that file system are exceeded.

Like user account quotas, a group's quota is exceeded when the number of blocks (or inodes) used on a particular file system is exceeded. However, the group blocks or inodes used only count toward a group's quota when the files that are produced are assigned the GID for the group. Files that are written by the members of the group that are not assigned the GID of the group do not count toward the group quota.

Note

Quota commands display block sizes of 1024-byte blocks.

A hard limit is one more unit (blocks, files, inodes) than will be allowed when the quota limit is active. The quota is up to, but not including the limit. For example, if you set a hard limit of 10,000 disk blocks for each user account in a file system, an account reaches the hard limit when 9,999 disk blocks have been allocated. If you want a maximum of 10,000 complete blocks for the user account, you must set the hard limit to 10,001.

9.3.4.2 Setting File System Quotas for User Accounts

To set a disk quota for a user, you can create a quota prototype or you can use an existing quota prototype and replicate it for the user. A quota prototype is an equivalence of an existing user's quotas to a prototype file, which is then used to generate identical user quotas for other users. Use the edquota command to create prototypes. If you do not have a quota prototype, create one by following these steps:

Log in as root and use the edquota command with the following syntax:
edquota proto-user users
For example, to set up a quota prototype named large for user eddie, enter the following command:
```
# edquota large eddie
```
The program creates the large quota prototype for user eddie. You must use a real login name for the users argument.

Edit the quota file opened by the edquota program to set quotas for each file system that user eddie can access.

To use an existing quota prototype for a user:

Enter the edquota command with the following syntax:
edquota -p proto-userusers
For example, to set a disk quota for marcy, using the large prototype, enter:
```
# edquota -p large marcy
```

Confirm that the quotas are what you want to set for user marcy. If not, edit the quota file and set new quotas for each file system that user marcy can access.

Refer to quota(1) and edquota(8) for more information.

9.4 Removing a User Account

To remove a user's account, you must remove all the files and directories from the account and rename the user's entry for the group and passwd files. You can rename an account manually or by using the removeuser utility.

9.4.1 Removing a User Account with the removeuser Utility

The removeuser utility automates the process of removing a user account. This utility performs the following tasks:

Removes the user's entry from the /etc/passwd file and any references to the user's account from the /etc/group file

Searches several administrative directories and files for occurrences of the user and informs you if they exist

Allows the removal of the home directory, which includes directories and files, and mail files

To use the removeuser utility, log in as root. At the prompt, enter:

# removeuser

The program responds with a series of prompts and messages, as shown in the following example:


Enter a login name to be removed or <RETURN> to exit: kalle
This is the entry for (kalle) in the /etc/passwd file:
 
 kalle:/v7ZY9/tF1z5w:12:15:Kalle Anderson:/usr/users/kalle:/ksh
Is this the entry you want to delete (y/n)? y
Working ...
Entry for (kalle) removed.
Searching relevant directories and files for user (kalle) ...
None found.
Do you want to remove the home directory, all subdirectories, 
files and mail for (kalle) (y/n)? y
The files for (kalle) will be lost if not backed up.
Are you sure you want to remove these files (y/n)? y
Removing /usr/users/kalle
 
Removing /usr/spool/mail/kalle
 
Finished removing user account for (kalle)

9.4.2 Removing a User Account Manually

To manually remove a user account from your system:

Remove the user's files and directories.

Remove the user's entry from the group file.

Remove the user's entry from the passwd file.

Remove the user's /usr/spool/mail/username file.

The following sections describe each task and provide instructions for removing the files and directories.

9.4.3 Removing a User's Files and Directories

Before removing files or directories from the user's account, follow these steps:

Make sure that the associated files and directories are not being used by other users on your system.

Back up the user's login directory to diskette or tape. Refer to Chapter 11 for more information.

To remove a user's files and directories:

Use the rm -r login_dir command to remove the user's login directory (including all of the directory's files and subdirectories). For example, to remove the login directory (including all of the files and subdirectories) for user marcy, enter:
```
# rm -r /usr/users/marcy
```

Use the rm mail_dir command to remove the user's mail directory. For example, to remove the mail file for user marcy, enter:
```
# rm /usr/spool/mail/marcy
```

Use the find command to ensure that no files remain that were owned by the user. For example, to verify that user marcy no longer owns files, enter:
```
# find /usr/users -user marcy -print
```
The find command locates user files that are links (identified by a notation of >1), user files within directories (identified by a notation of 1), or user directories (identified by a notation of 2). Refer to find(1) for more information.

If the find command locates any user files or directories, use the chown command to change the ownership to a different user (one who still needs to access the file). If there is no reason to save or maintain these files, remove them.

Remove the user's crontab and atjobs files if they exist. For example:


# rm /var/spool/cron/crontabs/marcy
# rm /var/spool/cron/atjobs/marcy

9.4.4 Removing a User's Account from the group File

Since users can be members of more than one group, modify all line entries in the group file that contain the user name within the user field.

To modify a group file entry:

Use the cp command to copy the group file to a temporary file.
```
# cp group group.sav
```

Open the group file and remove the user's name from each line entry in which it is listed. The screen displays a file similar to the following, which shows that user marcy is not a member of the users group:
```
system:*:0:root,diaz
daemon:*:1:daemon
uucp:*:2:uucp

.
.
.
users:*:15:diaz,chris

.
.
.
```

Close the file.

9.4.5 Removing a User's Account from the passwd File

After you remove a user's account from the passwd file, the system can no longer identify the user. When removing an account for a user, use the vipw command to delete the line entry that identifies the user. The vipw command allows you to edit the passwd file and at the same time locks the file to prevent others from using it. Refer to Section 9.2.1.1 for information on editing the passwd file.

If you maintain accounting on a monthly basis, do not remove the line entry for the user's account from the passwd file until the monthly accounting has been done. Since the accounting commands access the passwd file, removing the user account line entry will create inaccuracies in your accounting.

However, since your primary goal is to restrict the user from gaining access to the system, you can immediately suspend the user from logging in by substituting NO_LOGIN for the encrypted user password in the passwd file. For example, the line entry for user marcy is as follows:

marcy:IK7Nv8f86Jo:201:20:Marcy Swanson,dev,x1234:/usr/users/marcy:/bin/csh

Replace the encrypted password with NO_LOGIN as shown in the following example:

marcy:NO_LOGIN:201:20:Marcy Swanson,dev,x1234:/usr/users/marcy:/bin/csh

To disable network logins, delete the user's account from any proxy files such as the user's .rhosts file.

9.5 Adding and Removing Groups

This section describes how to:

Add a group with the addgroup utility

Add a group manually

Remove a group

Note

There are limits on length of command lines that may affect commands such as addgroup. The /usr/include/limits.h file limits LINE_MAX to 2048 characters. You must split command line entries into into multiple lines limited to 255 characters, or incorrect data may be added to the /etc/group file.

9.5.1 Adding a Group with the addgroup Utility

The addgroup utility automates the process of adding a group to the /etc/group file.

When you invoke the addgroup utility, the program responds with a series of prompts and messages asking you for the following information:

Group name

Group identification number (GID)

To use the addgroup utility, log in as root and enter the following command at the prompt:


# addgroup

The program responds with a series of prompts and messages. The brackets ([]) indicate the default response. Press Return to accept the default or enter a different response and press Return, as shown in the following example:


Enter a new group name or <Return> to exit: newgroup
Enter a new group number [112]: [Return]
Group newgroup was added to the /etc/group file.

The addgroup utility adds the new group to the /etc/group file.

9.5.2 Adding a Group Manually

To add a new group, add a line entry to the group file:

Use the cp command to copy the group file to a temporary file. For example, enter:
```
# cp group group.sav
```

Open the group file and add the required line entry. Be sure to include all four fields in this entry. A file is displayed similar to the following, which shows that users diaz, kalle, marcy, and chris belong to the users group that has a GID of 15:
```
system:*:0:root,diaz,kalle,marcy
daemon:*:1:daemon
uucp:*:2:uucp

.
.
.
users:*:15:diaz,kalle,marcy,chris
```

Close the file.

Use the vipw command to edit the passwd file to include the GID in the group_id field of each user who is a member of the group. Refer to Section 9.2.1.1 for more information about the passwd file.

If at a later date you change the group a user belongs to, be sure to change the parent directory's GID also.

9.5.3 Removing a Group

To remove a group that no longer has any members, delete the corresponding line from the group file as follows:

Log in as root and edit the passwd file line entry for each member of the group by using the vipw command. You can either assign a different group number or delete the current group number. If you assign a different group number, make sure that it corresponds to a current (or new) group entry in the group file. Refer to Section 9.2.1.1 for information on editing the passwd file.

Remove the original group line entry from the group file. To delete a group file entry:
1. Log in as root and move to the /etc directory.
2. Use the cp command to copy the group file to a temporary file.
```
# cp group group.sav
```
3. Open the group file and delete the appropriate group line entry.
4. Close the file.