Sun Microsystems System Administration Guide, Volume 1 (2000)

CHAPTER

Managing User Accounts and Groups

(Overview)

This chapter provides guidelines and planning information for managing user

accounts and groups. It also provides overview information about setting up user

accounts and groups in a network environment. This chapter includes information

about the files used to store user account and group information and about

customizing the user’s work environment.

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

“What Are User Accounts and Groups?” on page 36

“Guidelines for Managing User Accounts” on page 37

“Guidelines for Managing Groups” on page 43

“Tools for Managing User Accounts and Groups” on page 44

“Where User Account and Group Information Is Stored” on page 49

“Customizing a User’s Work Environment” on page 56

For step-by-step instructions on managing user accounts and groups, see Chapter 3.

What’s New in Managing Users and

Groups?

In this Solaris release, role-based access control (RBAC) provides a flexible way to

package superuser privileges for assignment to user accounts so that you don’t have

to give all superuser privileges to a user that needs to solve a specific problem.

See “Role-Based Access Control” in System Administration Guide, Volume

2 for more

information.

What Are User Accounts and Groups?

One of the basic system administration tasks 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

consists of four main components:

Component

Description

User name

A name that a user uses to log in to a system

(also known as a login name).

Password

A secret combination of characters that a

user must enter with a user name to gain

access to a system.

User’s home directory

A directory that is usually the user’s current

directory at login. It typically contains most

of the user’s files.

User initialization files

Shell scripts that control how the user’s

working environment is set up when a user

logs in to a system.

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 file and directory access only to users who

are part of a group (using the group permissions on a file or directory).

For example, you might have a directory containing top secret files that only a few

users should be able to access. You could set up a group called topsecret that

include the users working on the top secret project, and you could set up the top

secret files with read permission for the topsecret group. That way, only the users

in the topsecret group would be able to read the files.

There is also a special type of user account called a role, which is used to give

selected users special privileges. See “Role-Based Access Control” in System

Administration Guide, Volume

2 for more information.

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 service such as NIS or NIS+. A name 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 service for user accounts, users can

move from system to system using the same user account without having site-wide

user account information duplicated in every system’s /etc files. Using a name

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. User names must:

Be unique within your organization, which might span multiple domains

Contain from two to eight letters and numerals (the first character must be a letter

and at least one character must be a lowercase letter)

Not contain an underscore or space

It is helpful to establish a standard way of forming user names, and the 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 that 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 that still results in duplicate

names, you can use 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.

Note - 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.

Managing User Accounts and Groups (Overview)

User ID Numbers

Associated with each user name is a user identification (UID) number. The UID

number identifies the user name to any system on which the user attempts to log in,

and it 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, and they

are required for both regular user accounts and special system accounts. The table

below lists the UID numbers reserved for user accounts and system accounts.

TABLE 2-1

Reserved UID Numbers

User ID Numbers

Reserved For ...

0 - 99

root, daemon, bin, sys, etc.

System accounts

100 - 2147483647

Regular users

General purpose accounts

60001

nobody

Unauthenticated users

60002

noaccess

Compatibility with Solaris 2.0 and

compatible versions and SVR4

releases

Although UID numbers 0 through 99 are reserved, you can add a user with one of

these numbers. However, do not use them 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 1000 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. If need be, you can use duplicate

UIDs in an NIS+ domain if the supply of unique UIDs is exhausted.

Using Large User IDs and Group IDs

Previous Solaris software releases used 32-bit data types to contain the user IDs

(UIDs) and group IDs (GIDs), but UIDs and GIDs were constrained to a maximum

useful value of 60000. Starting with the Solaris 2.5.1 release and compatible versions,

the limit on UID and GID values has been raised to the maximum value of a signed

integer, or 2147483647.

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 table below describes interoperability issues with previous Solaris and Solaris

product releases.

TABLE 2-2

Interoperability Issues for UIDs/GIDs Over 60000

Category

Product/Command

Issues/Cautions

NFS^TM

SunOS^TM 4.0 NFS

NFS server and client code truncates large

UIDs and GIDs to 16 bits. This can create

Interoperability

software and

security problems if SunOS 4.0 and

compatible versions

compatible machines are used in an

environment where large UIDs and GIDs are

being used. SunOS 4.0 and compatible

systems require a patch.

Name Service

NIS name service

Users with UIDs above 60000 can log in or

Interoperability

File-based name

use the su command on systems running the

service

Solaris 2.5 and compatible versions, but their

UIDs and GIDs will be set to 60001 (nobody).

NIS+ name service

Users with UIDs above 60000 are denied

access on systems running Solaris 2.5 and

compatible versions and the NIS+ name

service.

Printed UIDs/GIDs OpenWindows File

Large UIDs and GIDs do not display

Manager

correctly if the OpenWindows^TM File

Manager is used with the extended file

listing display option.

Managing User Accounts and Groups (Overview)

TABLE 2-3

Large UID/GID Limitation Summary

A UID or GID Of ...

Limitations

Users in this category logging into systems running Solaris

60003 or greater

2.5 and compatible releases and the NIS or files name service

get a UID and GID of nobody.

Solaris 2.5 and compatible releases systems running the NFS

65535 or greater

version 2 software see UIDs in this category truncated to 16

bits, creating possible security problems.

Users in this category using the cpio command (using the

default archive format) to copy file see an error message for

each file and the UIDs and GIDs are set to nobody in the

archive.

SPARC based systems: Users in this category running SunOS

4.0 and compatible applications see EOVERFLOW returns

from some system calls, and their UIDs and GIDs are

mapped to nobody.

IA based systems: Users in this category running

SVR3-compatible applications will probably see EOVERFLOW

return codes from system calls.

IA based systems: If users in this category attempt to create

a file or directory on a mounted System V file system, the

System V file system returns an EOVERFLOW error.

The ps -l command displays a maximum five-digit UID so

100000 or greater

the printed column won’t be aligned when they include a

UID or GID larger than 99999.

262144 or greater

Users in this category using the cpio command (using -H

odc format) or the pax -x cpio command to copy files see

an error message returned for each file, and the UIDs and

GIDs are set to nobody in the archive.

1000000 or greater

Users in this category using the ar command have their

UIDs and GIDs set to nobody in the archive.

Users in this category using the tar command, the cpio -H

2097152 or greater

ustar command, or the pax -x tar command have their

UIDs and GIDs set to nobody.

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:

Phrases (beammeup)

Nonsense words made up of the first letters of every word in a phrase (swotrb

for SomeWhere Over The RainBow)

Words with numbers or symbols substituted for letters (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. 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 become disabled.

Managing User Accounts and Groups (Overview)

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 and the type of work done. As a general rule, you

should allocate at least 15 Mbytes of disk space for each user’s home directory.

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 System Administration Guide, Volume

To use the home directory anywhere on the network, you should always refer to it 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 (.login, .cshrc, .profile) in the user’s home directory.

See “Customizing a User’s Work Environment” on page 56 for detailed information

about customizing user initialization files for users. 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 separate directories, called 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.

Note - Do not use system initialization files (/etc/profile, /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, then 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” in System Administration Guide, Volume 2 for more

information.

Guidelines for Managing Groups

A group is a collection of users who can share files and other system resources. For

example, the set of users 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 16 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, the 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: staff (group 10). The primary group should already exist (if it doesn’t

exist, specify the group by a GID number). User names are not added to primary

groups. If they 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.

Managing User Accounts and Groups (Overview)

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+, which

enables you to centrally manage group memberships.

Tools for Managing User Accounts and

Groups

The table below lists the recommended tools for managing users and groups.

TABLE 2-4

Recommended Tools for Managing Users and Groups

If You Are

The Recommended And You Will Need To Start This Tool

Managing Users and

Tool Is

See ...

Groups ...

On remote and/or

AdminSuite^TM 2.3’s

Graphics monitor

Solstice AdminSuite

local systems in a

User and Group

running an X

2.3

Administration

networked, name

Manager (graphical

window

Guide

service (NIS, NIS+)

user interface)

environment such as

environment

CDE

On a local system

Admintool (graphical Graphics monitor

Chapter 3

user interface)

running an X

window system such

as CDE

The Solaris commands useradd and groupadd also let you set up users and groups

on a local system; however, the commands do not change name service maps or

tables. The table below describes the Solaris command used to manage user accounts

and groups if you are not using AdminSuite 2.3 or Admintool.

TABLE 2-5

Managing User Accounts and Groups by Using Solaris Commands

If You Use This Name Service

Then Use These

Task

Commands

Add a User Account

NIS+

nistbladm

nisclient

NIS

useradd

make

None

useradd

Modify a User Account

NIS+

nistbladm

NIS

usermod

make

None

usermod

Delete a User Account

NIS+

nistbladm

nisclient

NIS

userdel

make

None

userdel

Set Up User Account Defaults

NIS+

not available

NIS

useradd -D

make

None

useradd -D

Disable a User Account

NIS+

nistbladm

NIS

passwd -r nis -l

make

None

passwd -r files -l

Managing User Accounts and Groups (Overview)

TABLE 2-5

Managing User Accounts and Groups by Using Solaris Commands

(continued)

If You Use This Name Service

Then Use These

Task

Commands

Change a User’s Password

NIS+

passwd -r nisplus

NIS

passwd -r nis

None

passwd -r files

Sort User Accounts

NIS+

niscat

sort

NIS

ypcat

sort

None

awk

sort

Find a User Account

NIS+

nismatch

NIS

ypmatch

None

grep

Add a Group

NIS+

nistbladm

NIS

groupadd

make

None

groupadd

Modify Users in a Group

NIS+

nistbladm

NIS

groupmod

make

None

groupmod

Delete a Group

NIS+

nistbladm

TABLE 2-5

Managing User Accounts and Groups by Using Solaris Commands

(continued)

If You Use This Name Service Then Use These

Task

Commands

NIS

groupdel

make

None

groupdel

What You Can Do With Admintool

Admintool is a graphical user interface that enables you to set up user accounts on a

local system.

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 Admintool to remove one

account and re-add it with a different UID number. You cannot use Admintool to

modify a UID number of an existing user account.

If two user account have duplicate user names, use Admintool to modify one of

the accounts and change the user name.

If you do use Admintool 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.

Admintool’s Modify option lets you add or delete a user’s secondary groups.

Alternatively, you can use the Groups window to directly modify a group’s member

list.

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

Comment

Passwords

Managing User Accounts and Groups (Overview)

Home directory

Delete User Accounts

When you delete a user account with Admintool, the software deletes the entries in

the passwd and group files. In addition, you can delete the files in the user’s home

directory.

Add Customized User Initialization Files

Although you can’t create customized user initialization files with Admintool, you

can populate a user’s home directory with user initialization files located in a

specified “skeleton” directory.

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 Admintool for password administration, which includes 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, or specifying expiration

dates and password aging information.

Note - 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 use Admintool to lock the password

for an account. You can also enter an expiration date in the Expiration Date field to

set how long the user account is disabled.

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, and in the NIS name service, information is stored in maps.

Note - To avoid confusion, the location of the user account and group information is

generically referred to as a file rather than a file, 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 table below describes the passwd file fields.

Managing User Accounts and Groups (Overview)

TABLE 2-6

Fields in the passwd File

Field Name

Description

username

Contains the user or login name. User names should be unique

and consist of 1-8 letters (A-Z, a-z) and numerals (0-9). The first

character must be a letter, and at least one character must be a

lowercase letter. User names cannot contain underscores or

spaces.

password

Contains an x, a placeholder for the encrypted password. The

encrypted password is stored in the shadow file.

Contains a user identification (UID) number that identifies the

uid

user to the system. UID numbers for regular users should range

from 100 to 60000. All UID numbers should be unique.

Contains a group identification (GID) number that identifies the

gid

user’s primary group. Each GID number must be a whole

number between 0 and 60002 (60001 and 60002 are assigned to

nobody and noaccess, respectively).

comment

Usually contains the full name of the user. (This field is

informational only.) It is sometimes called the GECOS field

because it was originally used to hold the login information

needed to submit batch jobs to a mainframe running GECOS

(General Electric Computer Operating System) from UNIX

systems at Bell Labs.

home-directory

Contains user’s home directory path name.

Contains the user’s default login shell, which can be /bin/sh,

/bin/csh or /bin/ksh. Table 2-13 contains a description of

shell features.

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

(continued)

(Continuation)

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

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

TABLE 2-7

Default passwd File Entries

User Name

User ID

Description

root

Superuser account

daemon

Umbrella system daemon associated with

updating calendars, and so forth

bin

Administrative daemon associated with running

system binaries to perform some routine system

task

sys

Administrative daemon associated with system

logging or updating files in temporary

directories

adm

Administrative daemon associated with system

logging

Line printer daemon

uucp

uucp daemon

nuucp

uucp daemon

listen

Network listener daemon

nobody

60001

Anonymous user account, assigned by an NFS

server when a request is received from an

unauthorized root user. The nobody user

account is assigned to software processes that

do not need nor should have any special

permissions.

Managing User Accounts and Groups (Overview)

TABLE 2-7

Default passwd File Entries

(continued)

User Name

User ID

Description

noaccess

60002

Account assigned to a user or a process that

needs access to a system through some

application but without actually logging in.

nobody4

65534

SunOS 4.0 or 4.1 version of nobody user

account.

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 table below describes the shadow file fields.

TABLE 2-8

Fields in the shadow File

Field Name

Description

Contains the user or login name.

username

Might contain the following entries: a 13-character encrypted

password

user password; the string *LK*, which indicates an inaccessible

account; or the string NP, which indicates no password for the

account.

Indicates the number of days between January 1, 1970, and the

lastchg

last password modification date.

min

Contains the minimum number of days required between

password changes.

Contains the maximum number of days the password is valid

max

before the user is prompted to specify a new password.

TABLE 2-8

Fields in the shadow File

(continued)

Field Name

Description

inactive

Contains the number of days a user account can be inactive

before being locked.

expire

Contains the absolute date when the user account expires. Past

this date, the user cannot log in to the system.

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 table below describes the group file fields.

TABLE 2-9

Fields in the group File

Field Name

Description

group-name

Contains the name assigned to the group. For example, members of

the chemistry department in a university might be called chem.

Group names can have a maximum of eight characters.

Usually contains an asterisk or is empty. The group-password field is a

group-password

relic of earlier versions of UNIX. If a group has a password, the

newgrp command prompts users to enter it. However, there is no

utility to set the password.

Managing User Accounts and Groups (Overview)

TABLE 2-9

Fields in the group File

(continued)

Field Name

Description

gid

Contains the group’s GID number. It must be unique on the local

system, and should be unique across the entire organization. Each

GID number must be a whole number between 0 and 60002.

Numbers under 100 are reserved for system default group accounts.

User defined groups can range from 100 to 60000. (60001 and 60002

are reserved and assigned to nobody and noaccess, respectively.)

user-list

Contains a comma-separated list of user names, representing the

user’s secondary group memberships. Each user can belong to a

maximum of 16 secondary groups.

Default group file

The default Solaris group file contains the following system groups that support

some system-wide task, such as printing, network administration, and electronic

mail. Many of these having corresponding entries in the passwd file.

root::0:root

other::1:

bin::2:root,bin,daemon

sys::3:root,bin,sys,adm

adm::4:root,adm,daemon

uucp::5:root,uucp

mail::6:root

tty::7:root,tty,adm

lp::8:root,lp,adm

nuucp::9:root,nuucp

staff::10:

daemon::12:root,daemon

sysadmin::14:root

nobody::60001:

noaccess::60002:

nogroup::65534:

TABLE 2-10

Default group File Entries

Group Name

Group ID

Description

root

Superuser group

other

TABLE 2-10

Default group File Entries

(continued)

Group Name

Group ID

Description

bin

Administrative group associated with running

system binaries

sys

Administrative group associated with system

logging or temporary directories

adm

Administrative group associated with system

logging

uucp

Group associated with uucp functions

mail

Electronic mail group

tty

Group associated with tty devices

Line printer group

nuucp

Group associated with uucp functions

staff

General administrative group

daemon

Daemon group

sysadmin

Administratve group associated with Admintool

and Solstice AdminSuite tools

nobody

60001

Anonymous group assigned by an NFS server

when a request is received from an

unauthorized root user

noaccess

60002

nogroup

65534

Managing User Accounts and Groups (Overview)

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, but 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 table below.

TABLE 2-11

User Initialization Files for Bourne, C, and Korn Shells

Shell

User Initialization File

Purpose

Bourne

$HOME/.profile

Defines user’s environment at login

Defines user’s environment for all C shells;

$HOME/.cshrc

invoked after login shell

$HOME/.login

Defines user’s environment at login

Korn

$HOME/.profile

Defines user’s environment at login

Defines user’s environment at login in the

$HOME/$ENV

file; specified by the Korn shell’s ENV

environment variable

The Solaris environment provides default user initialization files for each shell in the

/etc/skel directory on each system, as shown in the table below.

TABLE 2-12

Default User Initialization Files

Shell

Default File

/etc/skel/local.login

/etc/skel/local.cshrc

Bourne or Korn

/etc/skel/local.profile

TABLE 2-12

Default User Initialization Files

(continued)

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. See “How to

Customize User Initialization Files” on page 72 for step-by-step instructions on how

to create sets of user initialization files for different types of users.

When you use Admintool 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:

Shell

Files Created

The /etc/skel/local.cshrc and the /etc/skel/local.login files

are copied into the user’s home directory and are renamed .cshrc and

.login.

Bourne and

The /etc/skel/local.profile file is copied into the user’s home

Korn

directory and renamed .profile.

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’ll 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.

Managing User Accounts and Groups (Overview)

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; do

not use /export/home/username/bin. $HOME works when the user logs in to

another system, when home directories are automounted.

To access files on a local disk, use global path names, like

/net/machine-name/directory-name. Any directory referenced by

/net/machine-name can be mounted automatically on any system on which the

user logs in, assuming the system is running AutoFS.

Shell Features

The table below 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.

TABLE 2-13

Basic Features of Bourne, C, and Korn Shells

Feature

Bourne

Korn

Known as the standard shell in

Yes

UNIX

Compatible syntax with Bourne

Yes

shell

Job control

Yes

History list

Yes

TABLE 2-13

Basic Features of Bourne, C, and Korn Shells

(continued)

Feature

Bourne

Korn

Command-line editing

Yes

Aliases

Yes

Single-character abbreviation for

Yes

Protection from overwriting

Yes

(noclobber)

Setting to ignore Control-d

Yes

(ignoreeof)

Enhanced cd

Yes

Initialization file separate from

Yes

.profile

Logout file

Yes

Shell Environment

A shell maintains an environment that includes a set of variables defined by the

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.

Managing User Accounts and Groups (Overview)

In the Bourne and Korn shells, you use the uppercase names with the setenv

command to set both shell and environment variables. You also have to use the

export command to finish setting environment variables. 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 table

below shows how to set environment variables in a user initialization file.

TABLE 2-14

Setting Environment Variables in a User Initialization File

If You Want to Set a User’s Environment

Then Add the Following Line to the User

Variables for The ...

Initialization File ...

C shell

setenv VARIABLE value

Example:

setenv MAIL /var/mail/ripley

Bourne or Korn shell

VARIABLE=value; export VARIABLE

Example:

MAIL=/var/mail/ripley;export MAIL

The table below describes environment and shell variables you might want to

customize in a user initialization file. For more information about variables used by

the different shells, see sh(1), ksh(1), or csh(1).

TABLE 2-15

Shell and Environment Variable Descriptions

Variable

Description

ARCH

Sets the user’s system architecture (for example, sun4, i386). This

variable can be set with ARCH = ‘uname -p‘ (in Bourne or Korn

shells) or setenv ARCH ‘uname -p‘ (in C shell). No built-in behavior

of the shell depends on this variable. It’s only a useful variable for

branching within shell scripts.

CALENDAR

Sets the path to the Calendar executables.

TABLE 2-15

Shell and Environment Variable Descriptions

(continued)

Variable

Description

CDPATH (or

Sets a variable used by the cd command. If the target directory of the

cd command is specified as a relative path name, the cd command

cdpath in the C

first looks for the target directory in the current directory (“.”). If the

shell)

target is not found, the path names listed in the CDPATH variable are

searched consecutively until the target directory is found and the

directory change is completed. If the target directory is not found, the

current working directory is left unmodified. For example, the CDPATH

variable is set to /home/jean, and two directories exist under /

home/jean: bin and rje. If you are in the /home/jean/bin

directory and type cd rje, you change directories to /home/jean/

rje, even though you do not specify a full path.

DESKSET

Sets the path to the DeskSet^TM executables.

history

Sets history for the C shell.

HOME (or home in

Sets the path to the user’s home directory.

the C shell)

LANG

Sets the locale.

LOGNAME

Defines the name of the user currently logged in. The default value of

LOGNAME is set automatically by the login program to the user name

specified in the passwd file. You should only need to refer to (not

reset) this variable.

LPDEST

Sets the user’s default printer.

Sets the path to the user’s mailbox.

MAIL

MANPATH

Sets the hierarchies of man pages available.

MANSECTS

Sets the hierarchies of man pages available.

OPENWINHOME

Sets the path to the OpenWindows subsystem.

Managing User Accounts and Groups (Overview)

TABLE 2-15

Shell and Environment Variable Descriptions

(continued)

Variable

Description

PATH (or path in

Lists, in order, the directories that the shell searches to find the program

to run when the user types a command. If the directory is not in the

the C shell)

search path, users must type the complete path name of a command.

The default PATH is automatically defined and set as specified in

.profile (Bourne or Korn shell) or .cshrc (C shell) as part of the

The order of the search path is important. When identical commands

exist in different locations, the first command found with that name is

used. For example, suppose that PATH is defined (in Bourne and Korn

shell syntax) as PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin

and a file named sample resides in both /usr/bin and /home/

jean/bin. If the user types the command sample without specifying

its full path name, the version found in /usr/bin is used.

prompt

Defines the shell prompt for the C shell.

PS1

Defines the shell prompt for the Bourne or Korn shell.

Sets the default shell used by make, vi, and other tools.

SHELL (or shell in

the C shell)

TERMINFO

Specifies the path name for an unsupported terminal that has been

added to the terminfo file. Use the TERMINFO variable in /etc/

profile or /etc/.login.

When the TERMINFO environment variable is set, the system first

checks the TERMINFO path defined by the user. If it does not find a

definition for a terminal in the TERMINFO directory defined by the

user, it searches the default directory, /usr/share/lib/terminfo,

for a definition. If it does not find a definition in either location, the

terminal is identified as “dumb.”

TERM (or term in

Defines the terminal. This variable should be reset in /etc/profile

or /etc/.login. When the user invokes an editor, the system looks

the C shell)

for a file with the same name as the definition of this environment

variable. The system searches the directory referenced by TERMINFO to

determine the terminal characteristics.

Sets the time zone, which is used to display dates, for example, in the

ls -l command. If TZ is not set in the user’s environment, the system

setting is used; otherwise, Greenwich Mean Time is used.

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 it.

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

Managing User Accounts and Groups (Overview)

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 table below describes some of the values for the LANG and LC environment

variables.

TABLE 2-16

Values for LANG and LC Variables

Value

Locale

German

French

iso_8859_1

English and European

Italian

japanese

Japanese

korean

Korean

Swedish

tchinese

Taiwanese

Examples—Setting the Locale Using the LANG Variables

The following examples show how to set the locale 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 can be set with a three-digit octal value. 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 table below,

which shows the file and directory permissions that are created for each of the octal

values of umask.

TABLE 2-17

Permissions for umask Values

umask Octal Value

File Permissions

Directory Permissions

rw-

rwx

rw-

r--

r-x

r--

-w-

-wx

-w-

--x

--- (none)

Managing User Accounts and Groups (Overview)

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

PATH=$PATH:$HOME/bin:/usr/local/bin:/usr/ccs/bin:.¹

MAIL=/var/mail/$LOGNAME²

NNTPSERVER=server1³

MANPATH=/usr/share/man:/usr/local/man⁴

PRINTER=printer1⁵

umask 022⁶

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

set path=($PATH $HOME/bin /usr/local/bin /usr/ccs/bin)¹

setenv MAIL /var/mail/$LOGNAME²

setenv NNTPSERVER server1³

setenv PRINTER printer1⁴

alias h history⁵

umask 022⁶

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. Sets the listed environment variables.

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.

Managing User Accounts and Groups (Overview)

Sun Microsystems System Administration Guide, Volume 1 (2000) - page 2