14    Trusted System Troubleshooting

This chapter describes problems that can occur on your system and gives guidance on how to avoid or correct from them. It provides you with insight on what is involved in the system startup, so you can examine critical files and programs required for correct system operation. Once the system is in single-user mode, there is no substitute for careful backup procedures. This is the only precaution that will avert serious data loss in your system.

The problems discussed in the following sections will prevent the system from booting.

14.1    Lock Files

The system security databases are critical to correct system operation. These databases use a lock file to synchronize rewrites to security-relevant databases. Before a process rewrites a database entry, it automatically creates the lock file. If the lock file already exists, the program assumes that another process is currently using the database and waits for the lock file to be removed. If the lock file persists and is not modified within a reasonable time period (currently 50 seconds), the program waiting for the lock file removes it and creates a new one, assuming that there has been a system crash or software error.

The system names lock files by appending a :t extension to the normal file name. For example, the system default database is stored in /etc/auth/system/default; its associated lock file is /etc/auth/system/default:t.

The system's startup scripts include lines that remove all lock files at system startup. The following files have associated lock files that can prevent correct operation of the system:

• /dev/console

• /etc/auth/system/default

• /etc/auth/system/devassign

• /etc/auth/system/ttys

• /tcb/files/auth/<a-z>/username

14.2    Invalid Maps

The system maintains two binary databases of mappings, one between user names and IDs and the other between group names and IDs. These are stored in the /etc/auth/system directory, in the files pw_id_map and gr_id_map.

Mapping names to IDs is a basic authentication and integrity mechanism of the system. If the underlying files on which the maps are based, /etc/passwd and /etc/group, are modified by trusted programs such as passwd, the programs automatically rebuild the binary databases. However, if the maps become inconsistent or their contents become corrupted, the system may not be able to map between names and IDs.

To prevent against corrupt mapping databases, the system removes the maps at startup. Because they are rebuilt every time the modification time of the underlying file is later than that of the database, the binary databases can be removed at any time. If the behavior of a program suggests that it cannot map a name to an ID, try removing the /etc/auth/system/pw_id_map or /etc/auth/system/gr_id_map file and running the failed program again. This procedure might avoid a system reboot.

14.3    Required Files and File Contents

The following files are required to run the system:

• /tcb/files/auth.db or /tcb/files/auth/r/root

• /etc/auth/system/ttys.db

• /etc/auth/system/default

• /etc/auth/system/devassign

• /etc/passwd

• /etc/group

• /etc/auth/system/pw_id_map

• /etc/auth/system/gr_id_map

• /sbin/rc[023]s

• /dev/console

• /dev/tty*

• /dev/pty*

• /dev/ptm*

• /dev/pts/*

• /sbin/sh

• /vmunix

14.3.1    The /tcb/files/auth/r/root File

When the system begins operation, it consults the security databases for various parameters. If any of the databases are corrupt, the system will not boot successfully. If possible, the startup programs report that there is a problem in the databases and to start a single-user shell at the system console to allow you to repair the system. In some cases, however, the system will not boot and you must repair the system from standalone procedures described in the manual System Administration.

If the protected password database entry for root is inconsistent, the system enters single-user mode, but assumes default characteristics for all security parameters of the shell it starts.

When the system is in single-user mode, you can create an authentication profile for root by entering the following command:

#  edauth root

The following example shows a typical authentication profile for root:

root:u_name=root:u_id#0:\
    :u_pwd=encrypted_password:\
    :u_minchg#0:u_pickpw:u_nullpw:u_restrict@:\
    :u_maxtries#100:u_lock@:chkent:

For a complete explanation of all the fields, see prpasswd(4). The following fields are required for the system to be able to boot:

• name
  Must contain root.

• u_name
  Must also be root.

• u_uid
  Must have a value of 0.

• u_pwd
  The encrypted version of the password. At authentication, the system checks the entered password against the encrypted version of the password. You can leave this field blank if you are creating the database entry.

• chkent
  As with all databases, the entry must end with the single word chkent.

The other fields in this entry are informational or are used to guard against unwanted account locking. The system overrides all conditions that can cause the root account to lock when changing to single-user mode.

14.3.2    The /etc/auth/system/ttys.db File

The terminal control database must have a valid entry for the system console. There must not be a :t lock file associated with this database. The entry for the system console must begin with the word console followed by a colon. It must end with the single word chkent. The only required field is t_devname, which must be set to a value of console. For example:

console:t_devname=console:chkent:

14.3.3    The /etc/auth/system/default File

The system default database must have an initial field default and must end with chkent. There must not be a :t lock file associated with this database.

The following example is typical:

default:\
        :d_name=default:\
        :d_boot_authenticate@:\
        :d_audit_enable@:\
        :d_pw_expire_warning#3456000:\
        :u_pwd=*:\
        :u_minchg#0:u_maxlen#20:u_exp#15724800:u_life#31449600:\
        :u_pickpw:u_genpwd:u_restrict@:u_nullpw@:\
        :u_genchars:u_genletters:u_maxtries#5:u_lock@:\
        :t_logdelay#1:t_maxtries#5:t_lock@:t_login_timeout#60:\
        :chkent:

14.3.4    The /etc/auth/system/devassign File

If the entry for the console is inconsistent, no application can be started. The field must start with the word console and end with the word chkent. The v_type field must be set to terminal.

The following example is typical:

console:v_devs=/dev/console:v_type=terminal:\
       :chkent:

14.3.5    The /etc/passwd File

The /etc/passwd file is the password database. This file must be present and its format must be correct (no encrypted passwords are updated in this file).

14.3.6    The /etc/group File

The /etc/group file is the group database. This file must be present and its format must be correct.

14.3.7    The /etc/auth/system/pw_id_map File

The /etc/auth/system/pw_id_map file is the user name to ID mapping database. This file must be consistent. The system rebuilds this file if it is not present.

14.3.8    The /etc/auth/system/gr_id_map File

The /etc/auth/system/gr_id_map file is the group name to ID mapping database. This file must be consistent. The system rebuilds this file if it is not present.

14.3.9    The /sbin/rc[023] Files

The /sbin/rc[023] files are used by init to change between run levels. Save copies of these files after installation.

14.3.10    The /dev/console File

The /dev/console file designates the character device associated with the system console. This file must be present for the system to boot.

14.3.11    The /dev/pts/* and /dev/tty* Files

The /dev/pts/* and /dev/tty* files are pseudo terminal devices used for interprocess communication.

14.3.12    The /sbin/sulogin File

The /sbin/sulogin executable file allows restricting access in single user mode to those users with the root password.

14.3.13    The /sbin/sh File

The /sbin/sh executable file must be present for the system to start a shell to transition to single-user mode.

14.3.14    The /vmunix File

The /vmunix file is the executable image of the operating system. The boot loading software loads the operating system into memory and transfers control to it at boot time.

14.4    Problems Logging In or Changing Passwords

If users experience problems logging in to the system or changing their passwords, examine the file attributes for the files in the security subset using the fverify command. For example, to verify the file attributes for the files in the OSFC2SEC400 subset, enter the following commands:

#  cd /
#  /usr/lbin/fverify < /usr/\.smdb\./OSFC2SEC400\.inv

The file attributes of the local user profile files are examined using the ls -l and authck -pf commands.

If a user complains of login troubles involving the inability to update the protected profile or to obtain a lock and you a running centralized account management, see Section 9.3.