Managing Initialization Files

Administrators who are setting up shell initialization files must consider certain details that are either not as important in standard UNIX systems or do not apply. The differences exist because of the following aspects of the Trusted Solaris implementation:

• Home directories are multilevel directories (MLDs).

• A profile shell can be used to restrict an account's access to commands.

• The execution of the profile(4) file is restricted in the Trusted Solaris environment.

As in the Solaris environment, files in the skeleton directory are copied into the user's home directory. However, in the Trusted Solaris environment, a user has a home directory for every label that the user works in. So, files from the skeleton directory are copied to the user's first home directory single-label directory (SLD).

A user's first SLD is created by the administrator during account creation. The first SLD is at the label of the creating process, ADMIN_LOW. The following example shows a user's directory structure after first login, and then the user's home directory structure after working at different labels.

Example 3-1 User Home Directory Structure after First Login

/home/.MLD.janez/.SLD.0:      [ADMIN_LOW]
/home/.MLD.janez/.SLD.1:      [CONFIDENTIAL]

Example 3-2 User Home Directory Structure after Working at Different Labels

/home/.MLD.janez/.SLD.0:      [ADMIN_LOW]
/home/.MLD.janez/.SLD.1:      [CONFIDENTIAL]
/home/.MLD.janez/.SLD.2:      [TOP SECRET A B]
/home/.MLD.janez/.SLD.3:      [SECRET]
/home/.MLD.janez/.SLD.4:      [CONFIDENTIAL A B]
/home/.MLD.janez/.SLD.5:      [SECRET A B]
/home/.MLD.janez/.SLD.6:      [TOP SECRET]
/home/.MLD.janez/.SLD.7:      [UNCLASSIFIED]

To copy or link the startup files into other labeled home directories requires setup on the part of the Security Administrator role. See "To Set Up Startup Files for Users" for the procedure.

This section provides the background information needed to understand how startup files are administered in the Trusted Solaris environment. Also see the man pages for the csh(1), ksh(1), sh(1), and pfexec(1) commands.

A set of startup files is sourced by the window system as it comes up. The user's login shell determines which startup files are sourced, as shown in the following table.

Another set of startup files is read whenever a user brings up a shell in a terminal emulator, such as the cmdtool, shelltool, or dtterm (see "Controlling Which Startup Files Are Read When a Shell Comes Up").

Controlling the Sourcing of Startup Files

In the Trusted Solaris CDE window system, as in the standard CDE window system, accounts get an editable $HOME/.dtprofile file which controls whether the .login or .profile files are read by the desktop at login. See also the man pages for login(1) and profile(4). See "The Sourcing of Startup Files for the Profile Shell User" for the one exception to this behavior.

.dtprofile Files

In the Trusted Solaris environment, by default the .login or .profile files are not sourced by the window system. A .dtprofile file controls the sourcing. One of the following .dtprofile files is copied into each account's $HOME/.dtprofile:

• An /etc/dt/config/sys.dtprofile file that was created by the site's Security Administrator role, if the file exists, or

• The default /usr/dt/config/sys.dtprofile

The following figure illustrates how $HOME/.dtprofile is installed.

Figure 3-1 How $HOME/.dtprofile is Installed

In the default /usr/dt/config/sys.dtprofile, the DTSOURCEPROFILE variable that enables the sourcing of either file is commented out. Removing the # before the DTSOURCEPROFILE definition in any of the versions of the sys.dtprofile file causes the appropriate startup file to be read by the window system.

See the comments in the /etc/dt/config/sys.dtprofile file and "To Invoke .login or .profile During Login", if changing the default is consistent with your site's security policy.

If any modifications to a .login or .profile accidentally prevent the user from logging in, the user may use the Failsafe Session option on the CDE Login screen. Failsafe Session allows a login without reading any startup files.

The Sourcing of Startup Files for the Profile Shell User

The algorithm for reading .dtprofile files when an account has a profile shell as its login shell prevents an account from executing commands that are not permitted to the account.

When a user's login shell is specified as the pfsh, pfcsh, or pfksh, the window system does not consult an account's home directory. The window system uses either the default /usr/dt/config/sys.dtprofile or a version modified by the Security Administrator role in /etc/dt/config/sys.dtprofile.

Figure 3-2 How $HOME/.dtprofile is Bypassed for Profile Shell Users

Controlling Which Startup Files Are Read When a Shell Comes Up

As in the Solaris environment, shell initialization files are used to set search paths and other environment variables and to execute some useful commands and functions. The following table shows which startup files are read by default when each type of shell is launched.

The .profile or .login files are invoked only if the shell is also identified as the account's login shell. A shell that is invoked with a prefix of - (for example: - csh) is a login shell. This means, for example, that when a C shell is started using csh (without a - prefix), the .login file is not executed.

Forcing dtterm to Source $HOME/.login or .profile

By default, a shell started by dtterm is not launched as a login shell. Therefore, the $HOME/.login and $HOME/.profile files are not read. Any user or role can enable dtterm to launch a login shell. See "To Force dtterm to Launch New Shells as Login Shells " for the procedure.

The default .profile file for all roles contains a function to alias the adminvi(1M) command to vi(1), but the function does not take effect unless the Dtterm*LoginShell: true entry is made in the $HOME/.Xdefaults-hostname file. See "To Alias vi to adminvi".

Administering Skeleton Directories

The default skeleton path used by the Users tool in the Solaris Management Console is /etc/skel. By default, a set of initialization files for each of the shells are copied from the /etc/skel directory into a user account's $HOME directory and renamed. The directory /etc/skel/tsol exists for role initialization files. The following example shows the default contents of the directory.

Example 3-3 Contents of the Default /etc/skel Directory

trusted% cd /etc/skel
trusted% ls -R
local.cshrc local.login local.profile tsol/
tsol:
role.link_files role.profile

In the Trusted Solaris environment, files are automatically copied from the skeleton directory only into the SLD at the account's minimum label. Either the user or the administrator must create the files .copy_files and .link_files as described in "Using .copy_files and .link_files", to ensure that subsequently-created SLDs get copies of initialization files.