Chapter 4 Managing User Accounts and Groups (Overview)

This chapter provides guidelines and planning information for managing user accounts and groups. This chapter also includes information about customizing the user's work environment.

This is a list of the overview information in this chapter.

• What's New in Managing Users and Groups?

• What Are User Accounts and Groups?

• Guidelines for Managing User Accounts

• Guidelines for Managing Groups

• Tools for Managing User Accounts and Groups

• Where User Account and Group Information Is Stored

• Customizing a User's Work Environment

For step-by-step instructions on managing user accounts and groups, see Chapter 5, Managing User Accounts and Groups (Tasks).

What's New in Managing Users and Groups?

This section describes new features for managing users and groups in the Solaris 9 release.

Solaris Management Console Tools Suite

The Solaris Management tools suite, available from the Solaris Management Console, enable you to manage all user and group features. For information on using the Solaris Management Console, see Chapter 2, Working With the Solaris^TM Management Console (Tasks). For information on performing specific user and group management tasks, see What You Can Do With Solaris User Management Tools.

Solaris Directory Services

You can manage user and group information in a LDAP (Lightweight Directory Access Protocol) directory service with the iPlanet^TM Directory Server, as well as other LDAP directory servers. Managing user and group information is also available in the NIS, NIS+, or files environment.

For information on setting up LDAP, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

For information on managing users and groups with iPlanet Directory Server, see iPlanet Directory Server 5.1 Administrator's Guide at the http://docs.iplanet.com site.

Managing Users and Resources With Projects

In the Solaris 9 release, users and groups can be members of a project, an identifier that indicates a workload component that can be used as the basis of system usage or resource allocation chargeback. Projects are part of the Solaris resource management feature that is used to manage system resources.

Users need to be a member of a project to successfully log in to a system running the Solaris 9 release. By default, users are a member of the group.staff project when the Solaris 9 release is installed and no other project information is configured.

User project information is stored in the /etc/project file, which can be stored on the local system (files), the NIS name service, or the LDAP directory service. You can use the Solaris Management Console to manage project information.

The /etc/project file must exist for users to log in successfully, but requires no administration if you are not using projects.

For more information on using or setting up projects, see “Projects and Tasks” in System Administration Guide: Resource Management and Network Services.

What Are User Accounts and Groups?

One basic system administration task is to set up a user account for each user at a site. A typical user account includes the information a user needs to log in and use a system, without having the system's root password. User account information has the following components:

Also, when you set up a user account, you can add the user to predefined groups of users. A typical use of groups is to set up group permissions on a file and directory, which allows access only to users who are part of that group.

For example, you might have a directory containing confidential files that only a few users should be able to access. You could set up a group called topsecret that includes the users working on the topsecret project. And, you could set up the topsecret files with read permission for the topsecret group. That way, only the users in the topsecret group would be able to read the files.

A special type of user account, called a role, is used to give selected users special privileges. For more information, see “Role-Based Access Control (Overview)” in System Administration Guide: Security Services.

A user or group can be a member of one or more projects. A project is an identifier that is used to chargeback system resources. For information on using projects, see “Projects and Tasks” in System Administration Guide: Resource Management and Network Services.

Guidelines for Managing User Accounts

The following sections describe some guidelines and planning information for creating user accounts.

Name Services

If you are managing user accounts for a large site, you might want to consider using a name or directory service such as LDAP, NIS, or NIS+. A name or directory service enables you to store user account information in a centralized manner instead of storing user account information in every system's /etc files. When using a name or directory service for user accounts, users can move from system to system using the same user account without having site-wide user account information duplicated on every system. Using a name or directory service also promotes centralized and consistent user account information.

User (Login) Names

User names, also called login names, let users access their own systems and remote systems that have the appropriate access privileges. You must choose a user name for each user account you create.

Keep the following guidelines in mind when creating user or role names:

• Be unique within your organization, which might span multiple domains

• Contain from two to eight letters and numerals. The first character should be a letter and at least one character should be a lowercase letter.

Even though user names can include a period (.), underscore (_), or hyphen (-), using these characters is not recommended because they can cause problems with some software products.

Consider establishing a standard way of assigning user names so they are easier for you to track. Also, names should be easy for users to remember. A simple scheme when selecting a user name is to use the first name initial and first seven letters of the user's last name. For example, Ziggy Ignatz becomes zignatz. If this scheme results in duplicate names, you can use the first initial, middle initial, and the first six characters of the user's last name. For example, Ziggy Top Ignatz becomes ztignatz. If this scheme still results in duplicate names, consider using the following scheme:

• The first initial, middle initial, first five characters of the user's last name,

• and the number 1, or 2, or 3, and so on, until you have a unique name.

Each new user name must be distinct from any mail aliases known to the system or to an NIS or NIS+ domain. Otherwise, mail might be delivered to the alias rather than to the actual user.

User ID Numbers

Associated with each user name is a user identification (UID) number. The user UID identifies the user name to any system on which the user attempts to log in. And, the user UID is used by systems to identify the owners of files and directories. If you create user accounts for a single individual on a number of different systems, always use the same user name and user ID. In that way, the user can easily move files between systems without ownership problems.

UID numbers must be a whole number less than or equal to 2147483647. UID numbers are required for both regular user accounts and special system accounts. The following table lists the UID numbers reserved for user accounts and system accounts.

Although UID numbers 0 through 99 are reserved, you can add a user with one of these numbers. However, do not use 0 through 99 for regular user accounts. By definition, root always has UID 0, daemon has UID 1, and pseudo-user bin has UID 2. In addition, you should give uucp logins and pseudo user logins, like who, tty, and ttytype, low UIDs so they fall at the beginning of the passwd file.

As with user (login) names, you should adopt a scheme to assign unique UIDs. Some companies assign unique employee numbers, and administrators add a number to the employee number to create a unique UID number for each employee.

To minimize security risks, you should avoid reusing the UIDs from deleted accounts. If you must reuse a UID, “wipe the slate clean” so the new user is not affected by attributes set for a former user. For example, a former user might have been denied access to a printer by being included in a printer deny list, but that attribute might not be appropriate for the new user.

Using Large User IDs and Group IDs

UIDs and GIDs can be assigned up to the maximum value of a signed integer, or 2147483647.

However, UIDs and GIDs over 60000 do not have full functionality and are incompatible with many Solaris features, so avoid using UIDs or GIDs over 60000.

The following table describes interoperability issues with Solaris products and previous Solaris releases.

Passwords

Although user names are publicly known, passwords must be kept secret and known only to users. Each user account should be assigned a password, which is a combination of six to eight letters, numbers, or special characters. You can set a user's password when you create the user account and have the user change it when logging in to a system for the first time.

To make your computer systems more secure, ask users to change their passwords periodically. For a high level of security, you should require users to change their passwords every six weeks. Once every three months is adequate for lower levels of security. System administration logins (such as root and sys) should be changed monthly, or whenever a person who knows the root password leaves the company or is reassigned.

Many breaches of computer security involve guessing a legitimate user's password. You should make sure that users avoid using proper nouns, names, login names, and other passwords that a person might guess just by knowing something about the user.

Good choices for passwords include the following:

• Phrases (beammeup)

• Nonsense words made up of the first letters of every word in a phrase. For example, swotrb for SomeWhere Over The RainBow.

• Words with numbers or symbols substituted for letters. For example, sn00py for snoopy.

Do not use these choices for passwords:

• Your name, forwards, backwards, or jumbled

• Names of family members or pets

• Car license numbers

• Telephone numbers

• Social Security numbers

• Employee numbers

• Names related to a hobby or interest

• Seasonal themes, such as Santa in December

• Any word in the dictionary

Password Aging

If you are using NIS+ or the /etc files to store user account information, you can set up password aging on a user's password. Starting in the Solaris 9 Update 2 release, password aging is also supported in the LDAP directory service.

Password aging enables you to force users to change their passwords periodically or to prevent a user from changing a password before a specified interval. If you want to prevent an intruder from gaining undetected access to the system by using an old and inactive account, you can also set a password expiration date when the account becomes disabled. You can set password aging attributes with the passwd command or the Solaris Management Console's Users Tool.

Home Directories

The home directory is the portion of a file system allocated to a user for storing private files. The amount of space you allocate for a home directory depends on the kinds of files the user creates, large or small, and the number of files created.

A home directory can be located either on the user's local system or on a remote file server. In either case, by convention the home directory should be created as /export/home/username. For a large site, you should store home directories on a server. Use a separate file system for each /export/homen directory to facilitate backing up and restoring home directories. For example, /export/home1, /export/home2.

Regardless of where their home directory is located, users usually access their home directories through a mount point named /home/username. When AutoFS is used to mount home directories, you are not permitted to create any directories under the /home mount point on any system. The system recognizes the special status of /home when AutoFS is active. For more information about automounting home directories, see “Task Overview for Autofs Administration” in System Administration Guide: Resource Management and Network Services.

To use the home directory anywhere on the network, you should always refer to the home directory as $HOME, not as /export/home/username. The latter is machine-specific. In addition, any symbolic links created in a user's home directory should use relative paths (for example, ../../../x/y/x), so the links will be valid no matter where the home directory is mounted.

User's Work Environment

Besides having a home directory to create and store files, users need an environment that gives them access to the tools and resources they need to do their work. When a user logs in to a system, the user's work environment is determined by initialization files that are defined by the user's startup shell, such as the C, Korn, or Bourne shell.

A good strategy for managing the user's work environment is to provide customized user initialization files, such as .login, .cshrc, .profile, in the user's home directory. For detailed information about customizing user initialization files for users, see Customizing a User's Work Environment. After you create the customized user initialization files, you can add them to a user's home directory when you create a new user account.

A recommended one-time task is to set up skeleton directories on a server. You can use the same server where the user's home directories are stored. The skeleton directories enable you to store customized user initialization files for different types of users.

Do not use system initialization files, such as /etc/profile or /etc/.login, to manage a user's work environment, because they reside locally on systems and are not centrally administered. For example, if AutoFS is used to mount the user's home directory from any system on the network, you would have to modify the system initialization files on each system to ensure a consistent environment when a user moved from system to system.

Another way to customize user accounts is through role-based access control. See “Role-Based Access Control (Overview)” in System Administration Guide: Security Services for more information.

Guidelines for Managing Groups

A group is a collection of users who can share files and other system resources. For example, a set of users that are working on the same project could be formed into a group. A group is traditionally known as a UNIX group.

Each group must have a name, a group identification (GID) number, and a list of user names that belong to the group. A GID identifies the group internally to the system. The two types of groups that a user can belong to are:

• Primary group – Specifies a group that the operating system assigns to files created by the user. Each user must belong to a primary group.

• Secondary groups – Specifies one or more groups to which a user also belongs. Users can belong to up to 15 secondary groups.

Sometimes a user's secondary group is not important. For example, ownership of files reflect the primary group, not any secondary groups. Other applications, however, might rely on a user's secondary memberships. For example, a user has to be a member of the sysadmin group (group 14) to use the Admintool software, but it doesn't matter if group 14 is his or her current primary group.

The groups command lists the groups that a user belongs to. A user can have only one primary group at a time. However, a user can temporarily change the user's primary group, with the newgrp command, to any other group in which the user is a member.

When adding a user account, you must assign a primary group for a user or accept the default group, staff (group 10). The primary group should already exist. If the primary group does not exist, specify the group by a GID number. User names are not added to primary groups. If user names were, the list might become too long. Before you can assign users to a new secondary group, you must create the group and assign it a GID number.

Groups can be local to a system or can be managed through a name service. To simplify group administration, you should use a name service like NIS or a directory service like LDAP, which enables you to centrally manage group memberships.

Tools for Managing User Accounts and Groups

The following table lists the recommended tools for managing users and groups. These tools are all included in the Solaris Management Console suite of tools. For information about starting and using the Solaris Management Console, see Chapter 2, Working With the Solaris^TM Management Console (Tasks).

For information on the Solaris management commands that can be used to manage user accounts and groups if you are not using the Solaris Management Console, see Table 1–6. These commands provide the same functionality as the Solaris management tools, including authentication and name service support.

What You Can Do With Solaris User Management Tools

The Solaris user management tools enable you to manage user accounts on a local system or in a name service environment.

This table describes the tasks you can do with Users Tool's User Accounts feature.

Managing Home Directories With the Solaris Management Console

Keep the following in mind when using the Solaris Management Console tools to manage user home directories:

• If you use the Users Tool's Add User Wizard to add a user account and you specify the user's home directory as /export/home/username, the home directory is automatically setup to be automounted, and the following entry is added to the passwd file:

  /home/username

• The only way you can use Users Tool to set up a user account that does not automount the home directory is to set up a user account template that disables this feature. Then, you can add users with this template. There is no way to disable this feature with the Add User Wizard.

• You can use the smuser add command with the -x autohome=N option to add a user without automounting the user's home directory. However, there is no option to the smuser delete command to remove the home directory after the user is added. You would have to remove the user and the user's home directory with the Users Tool

Modify User Accounts

Unless you define a user name or UID number that conflicts with an existing one, you should never need to modify a user account's login name or UID number. Use the following steps if two user accounts have duplicate user names or UID numbers:

• If two user accounts have duplicate UID numbers, use the Users Tool to remove one account and re-add it with a different UID number. You cannot use the Users Tool to modify a UID number of an existing user account.

• If two user accounts have duplicate user names, use the Users Tool to modify one of the accounts and change the user name.

If you do use the Users Tool to change a user name, the home directory's ownership is changed, if a home directory exists for the user.

One part of a user account that you can change is a user's group memberships. Select Properties from Users Tool's Action menu to add or delete a user's secondary groups. Alternatively, you can use the Groups Tool to directly modify a group's member list.

You can also modify the following parts of a user account:

• Description (comment)

• Login shell

• Passwords and password options

• Home directory and home directory access

• Rights and roles

Delete User Accounts

When you delete a user account with the Users Tool, the software deletes the entries in the passwd and group files. In addition, you can delete the files in the user's home directory and mail directory.

Add Customized User Initialization Files

Although you cannot create customized user initialization files with the Users Tool, you can populate a user's home directory with user initialization files located in a specified “skeleton” directory. You can do this by creating a user template with the User Templates tool and specifying a skeleton directory from which to copy user initialization files.

You can customize the user initialization templates in the /etc/skel directory and then copy them to users' home directories.

Administer Passwords

You can use Users Tool for password administration, which includes the following capabilities:

• Specifying a normal password for a user account

• Enabling users to create their own passwords during their first login

• Disabling or locking a user account

• Specifying expiration dates and password aging information.

Password aging is not supported by the NIS name service.

Disable User Accounts

Occasionally, you might need to temporarily or permanently disable a login account. Disabling or locking a user account means that an invalid password, *LK*, is assigned to the user account, preventing future logins.

The easiest way to disable a user account is to lock the password for an account with Users Tool. You can also enter an expiration date in the account availability section of the User Properties screen to set a limit on how long the account is active.

Other ways to disable a user account is to set up password aging or to change the user's password.

Where User Account and Group Information Is Stored

Depending on your site policy, you can store user account and group information in a name service or a local system's /etc files. In the NIS+ name service, information is stored in tables, in the NIS name service, information is stored in maps, and in the LDAP directory service, information is stored in indexed database files.

To avoid confusion, the location of the user account and group information is generically referred to as a file rather than as a database, table or map.

Most of the user account information is stored in the passwd file. However, password encryption and password aging is stored in the passwd file when using NIS or NIS+ and in the /etc/shadow file when using /etc files. Password aging is not available when using NIS.

Group information is stored in the group file.

Fields in the passwd File

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

username:password:uid:gid:comment:home-directory:login-shell

For example:

kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh

The following table describes the passwd file fields.

Default passwd File

The default Solaris passwd file contains entries for standard daemons, processes usually started at boot time to perform some system-wide task, such as printing, network administration, and port monitoring.

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:/:

Fields in the shadow File

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

username:password:lastchg:min:max:warn:inactive:expire

For example:

rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

The following table describes the shadow file fields.

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.

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 groups 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:

Customizing a User's Work Environment

Part of setting up a user's home directory is providing user initialization files for the user's login shell. A user initialization file is a shell script that sets up a work environment for a user after the user logs in to a system. Basically, you can perform any task in a user initialization file that you can do in a shell script. However, its primary job is to define the characteristics of a user's work environment, such as a user's search path, environment variables, and windowing environment. Each login shell has its own user initialization file or files, which are listed in the following table.

The Solaris environment provides default user initialization files for each shell in the /etc/skel directory on each system, as shown in the following table.

You can use these files as a starting point and modify them to create a standard set of files that provide the work environment common to all users. Or, you can modify them to provide the working environment for different types of users. For step-by-step instructions on how to create sets of user initialization files for different types of users, see How to Customize User Initialization Files.

When you use the Users Tool to create a new user account and select the create home directory option, the following files are created, depending on which login shell is selected:

If you use the useradd command to add a new user account and specify the /etc/skel directory by using the -k and -m options, all three /etc/skel/local* and /etc/skel/.profile files are copied into the user's home directory. At this point, you will need to rename them to whatever is appropriate for the user's login shell.

Using Site Initialization Files

The user initialization files can be customized by both the administrator and the user. This important feature can be accomplished with centrally located and globally distributed user initialization files, called site initialization files. Site initialization files enable you to continually introduce new functionality to the user's work environment, while enabling the user to customize the user's initialization file.

When you reference a site initialization file in a user initialization file, all updates to the site initialization file are automatically reflected when the user logs in to the system or when a user starts a new shell. Site initialization files are designed for you to distribute site-wide changes to users' work environments that you did not anticipate when you added the users.

Any customization that can be done in a user initialization file can be done in a site initialization file. These files typically reside on a server, or set of servers, and appear as the first statement in a user initialization file. Also, each site initialization file must be the same type of shell script as the user initialization file that references it.

To reference a site initialization file in a C-shell user initialization file, place a line similar to the following at the beginning of the user initialization file:

source /net/machine-name/export/site-files/site-init-file

To reference a site initialization file in a Bourne- or Korn-shell user initialization file, place a line similar to the following at the beginning of the user initialization file:

. /net/machine-name/export/site-files/site-init-file

Avoid Local System References

You should not add specific references to the local system in the user's initialization file. You want the instructions in a user initialization file to be valid regardless of the system to which the user logs in. For example:

• To make a user's home directory available anywhere on the network, always refer to the home directory with the variable $HOME. For example, use $HOME/bin instead of /export/home/username/bin. $HOME works when the user logs in to another system and the home directories are automounted.

• To access files on a local disk, use global path names, like /net/system-name/directory-name. Any directory referenced by /net/system-name can be mounted automatically on any system on which the user logs in, assuming the system is running AutoFS.

Shell Features

The following table lists basic shell features that each shell provides, which can help you determine what you can and can't do when creating user initialization files for each shell.

Shell Environment

A shell maintains an environment that includes a set of variables defined by the login program, the system initialization file, and the user initialization files. In addition, some variables are defined by default. A shell can have two types of variables:

• Environment variables – Variables that are exported to all processes spawned by the shell. Their settings can be seen with the env command. A subset of environment variables, like PATH, affects the behavior of the shell itself.

• Shell (local) variables – Variables that affect only the current shell. In the C shell, a set of these shell variables have a special relationship to a corresponding set of environment variables. These shell variables are user, term, home, and path. The value of the environment variable counterpart is initially used to set the shell variable.

In the C shell, you use the lowercase names with the set command to set shell variables and use uppercase names with the setenv command to set environment variables. If you set a shell variable, the shell sets the corresponding environment variable and vice versa. For example, if you update the path shell variable with a new path, the shell also updates the PATH environment variable with the new path.

In the Bourne and Korn shells, you can use the uppercase variable name equal to some value to set both shell and environment variables. You also have to use the export command to activate the variables for any subsequently executed commands.

For all shells, you generally refer to shell and environment variables by their uppercase names.

In a user initialization file, you can customize a user's shell environment by changing the values of the predefined variables or by specifying additional variables. The following table shows how to set environment variables in a user initialization file.

The following table describes environment and shell variables that you might want to customize in a user initialization file. For more information about variables that are used by the different shells, see sh(1), ksh(1), or csh(1).

The PATH Variable

When the user executes a command by using the full path, the shell uses that path to find the command. However, when users specify only a command name, the shell searches the directories for the command in the order specified by the PATH variable. If the command is found in one of the directories, the shell executes the command.

A default path is set by the system, but most users modify it to add other command directories. Many user problems related to setting up the environment and accessing the right version of a command or a tool can be traced to incorrectly defined paths.

Setting Path Guidelines

Here are some guidelines for setting up efficient PATH variables:

• If security is not a concern, put the current working directory (.) first in the path. However, including the current working directory in the path poses a security risk that you might want to avoid, especially for superuser.

• Keep the search path as short as possible. The shell searches each directory in the path. If a command is not found, long searches can slow down system performance.

• The search path is read from left to right, so you should put directories for commonly used commands at the beginning of the path.

• Make sure directories are not duplicated in the path.

• Avoid searching large directories, if possible. Put large directories at the end of the path.

• Put local directories before NFS^TM mounted directories to lessen the chance of “hanging” when the NFS server does not respond and to reduce unnecessary network traffic.

Examples—Setting a User's Default Path

The following examples show how to set a user's default path to include the home directory and other NFS mounted directories. The current working directory is specified first in the path. In a C-shell user initialization file, you would add the following:

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

In a Bourne- or Korn-shell user initialization file, you would add the following:

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin
export PATH

Locale Variables

The LANG and LC environment variables specify the locale-specific conversions and conventions for the shell, like time zones, collation orders, and formats of dates, time, currency, and numbers. In addition, you can use the stty command in a user initialization file to set whether the system will support multibyte characters.

LANG sets all possible conversions and conventions for the given locale. If you have special needs, you can set various aspects of localization separately through these LC variables: LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_NUMERIC, LC_MONETARY, and LC_TIME.

The following table describes some of the values for the LANG and LC environment variables.

Examples—Setting the Locale Using the LANG Variables

The following examples show how to set the locale by using the LANG environment variables. In a C-shell user initialization file, you would add the following:

setenv LANG DE

In a Bourne- or Korn-shell user initialization file, you would add the following:

LANG=DE; export LANG

Default File Permissions (umask)

When you create a file or directory, the default file permissions assigned to the file or directory are controlled by the user mask. The user mask is set by the umask command in a user initialization file. You can display the current value of the user mask by typing umask and pressing Return.

The user mask contains the following octal values:

• The first digit sets permissions for the user

• The second sets permissions for group

• The third sets permissions for other, also referred to as “world”

Note that if the first digit is zero, it is not displayed. For example, if umask is set to 022, 22 is displayed.

To determine the umask value you want to set, subtract the value of the permissions you want from 666 (for a file) or 777 (for a directory). The remainder is the value to use with the umask command. For example, suppose you want to change the default mode for files to 644 (rw-r--r--). The difference between 666 and 644 is 022, which is the value you would use as an argument to the umask command.

You can also determine the umask value you want to set by using the following table, which shows the file and directory permissions that are created for each of the octal values of umask.

The following line in a user initialization file sets the default file permissions to rw-rw-rw-.

umask 000

Examples of User and Site Initialization Files

The following sections provide examples of user and site initialization files that you can use to start customizing your own initialization files. Many of the examples use system names and paths that you need to change for your particular site.

Example—.profile File

1 PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:. 
2 MAIL=/var/mail/$LOGNAME 
3 NNTPSERVER=server1 
4 MANPATH=/usr/share/man:/usr/local/man 
5 PRINTER=printer1 
6 umask 022 
7 export PATH MAIL NNTPSERVER MANPATH PRINTER 

1. Defines the user's shell search path.

2. Defines the path to the user's mail file.

3. Defines the user's Usenet news server.

4. Defines the user's search path for man pages.

5. Defines the user's default printer.

6. Sets the user's default file creation permissions.

7. Sets the listed environment variables.

Example—.cshrc File

1 set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin)
2 setenv MAIL /var/mail/$LOGNAME 
3 setenv NNTPSERVER server1 
4 setenv PRINTER printer1 
5 alias h history 
6 umask 022 
7 source /net/server2/site-init-files/site.login 

1. Defines the user's shell search path.

2. Defines the path to the user's mail file.

3. Defines the user's Usenet news server.

4. Defines the user's default printer.

5. Creates an alias for the history command. The user will need to type only h to run the history command.

6. Sets the user's default file creation permissions.

7. Sources the site initialization file.

Example—Site Initialization File

The following shows an example site initialization file in which a user can choose a particular version of an application.

# @(#)site.login
main: 
echo "Application Environment Selection"
echo ""
echo "1. Application, Version 1"
echo "2. Application, Version 2"
echo "" 
echo -n "Type 1 or 2 and press Return to set your 
application environment: " 

set choice = $<	

if ( $choice !~ [1-2] ) then 
goto main 
endif 

switch ($choice) 

case "1": 
setenv APPHOME /opt/app-v.1 
breaksw 

case "2": 
setenv APPHOME /opt/app-v.2 
endsw

This site initialization file could be referenced in a user's .cshrc file (C shell users only) with the following line:

source /net/server2/site-init-files/site.login

In this line, the site initialization file is named site.login and is located on a server named server2. This line also assumes that the automounter is running on the user's system.