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. The components of user account information are described in User Account Components.
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.
User Account Components
The following sections describe the specific components of a user account.
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 that you create.
Consider establishing a standard way of assigning user names so that 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
to create a user name:
The first initial, middle initial, first five characters of the user's last name
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 that are
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.
For detailed guidelines on setting up user (login) names, see Guidelines for Using User Names, User IDs, and Group IDs.
User ID Numbers
Associated with each user name is a user identification number (UID). The UID
number identifies the user name to any system on which the user attempts
to log in. And, the UID number 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 ID number. In that way, the user can easily move
files between systems without ownership problems.
UID numbers must be a whole number that is 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 that are reserved for
user accounts and system accounts.
Table 4-2 Reserved UID Numbers
UID Numbers |
User or Login Accounts |
Description |
|---|
0 – 99 |
root, daemon, bin, sys, and so on |
Reserved
for use by the Solaris OS |
100 – 2147483647 |
Regular users |
General purpose accounts |
60001 and
65534 |
nobody and nobody4 |
Anonymous users |
60002 |
noaccess |
Non trusted users |
Do not assign UIDs 0 through 99. These UIDs are reserved for allocation
by the Solaris Operating System. 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, such as who, tty, and ttytype,
low UIDs so that they fall at the beginning of the passwd file.
For additional guidelines on setting up UIDs, see Guidelines for Using User Names, User IDs, and Group IDs.
As with user (login) names, you should adopt a scheme to assign
unique UID numbers. Some companies assign unique employee numbers. Then, 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 that 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. However, that attribute might be inappropriate
for the new user.
Using Large User IDs and Group IDs
UIDs and group IDs (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.
Table 4-3 Interoperability Issues for UIDs or GIDs Over 60000
Category |
Product
or Command |
Issue |
|---|
NFS interoperability |
SunOS 4.0 NFS software and compatible releases |
NFS server and client
code truncates large UIDs and GIDs to 16 bits. This situation can create
security problems if systems running SunOS 4.0 and compatible releases are used in
an environment where large UIDs and GIDs are being used. Systems running SunOS
4.0 and compatible releases require a patch to avoid this problem. |
Name service interoperability |
NIS
name service and file-based name service |
Users with UIDs greater than 60000 can
log in or use the su command on systems running the Solaris 2.5
(and compatible releases). However, their UIDs and GIDs will be set to 60001
(nobody). |
|
NIS+ name service |
Users with UIDs greater than 60000 are denied access on
systems running Solaris 2.5 (and compatible releases) and the NIS+ name service. |
Table 4-4 Large UID or GID Limitation Summary
UID or
GID |
Limitations |
|---|
60003 or greater |
Users who log in to systems running Solaris 2.5 (and
compatible releases) and the NIS or files name service get a UID and
GID of nobody. |
65535 or greater |
Systems running Solaris 2.5 (and compatible releases) with the NFS version 2 software truncate UIDs to 16 bits, creating possible security problems. Users who use the cpio command with the default archive format to copy a file see an error message for each file. And, the UIDs and GIDs are set to nobody in the archive. x86 based systems: Users that run SVR3-compatible applications will probably see EOVERFLOW return codes from system calls. x86 based systems: If users attempt to create a file or directory on a mounted System V file system, the System V file system returns an EOVERFLOW error.
|
100000 or greater |
The ps -l command displays a maximum
five-digit UID. So, the printed column won't be aligned when it includes a
UID or GID larger than 99999. |
262144 or greater |
Users who use the cpio
command with the -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 who use
the ar command have their UIDs and GIDs set to nobody in
the archive. |
2097152 or greater |
Users who use the tar command, the cpio -H ustar command,
or the pax -x tar command have their UIDs and GIDs set to nobody. |
UNIX Groups
A group is a collection of users who can share files and other
system resources. For example, users who 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 number identifies
the group internally to the system.
The two types of groups that a user can belong to are
as follows:
Primary group – Specifies a group that the operating system assigns to files that are 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.
For detailed guidelines on setting up group names, see Guidelines for Using User Names, User IDs, and Group IDs.
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 group memberships. For example, a user has to be
a member of the sysadmin group (group 14) to use the Admintool software
in previous Solaris releases. However, 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 added to primary groups, 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 managed through a name service.
To simplify group administration, you should use a name service such as NIS
or a directory service such as LDAP. These services enable you to centrally
manage group memberships.
User Passwords
You can specify a password for a user when you add the
user. Or, you can force the user to specify a password when the
user first logs in.
User passwords must comply with the following syntax:
Password length must at least match the value identified by the PASSLENGTH variable in the /etc/default/passwd file. By default, PASSLENGTH is set to 6.
The first 6 characters of the password must contain at least two alphabetic characters and have at least one numeric or special character.
Although user names are publicly known, passwords must be kept secret and known
only to users. Each user account should be assigned a password. The password
can be a combination of six to eight letters, numbers, or special characters.
To make your computer systems more secure, users should 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 (spelled forwards, backwards, or jumbled)
Names of family members or pets
Car license numbers
Telephone numbers
Social Security numbers
Employee numbers
Words related to a hobby or interest
Seasonal themes, such as Santa in December
Any word in the dictionary
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, their size,
and the number of files that are 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: 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 that the links are valid no matter
where the home directory is mounted.
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 you use 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'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. These files 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.
Note - Do not use system initialization files, such as /etc/profile or /etc/.login,
to manage a user's work environment. These files 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 whenever
a user moved from system to system.
For detailed information about customizing user initialization files for users, see Customizing a User's Work Environment.
Another way to customize user accounts is through role-based access control (RBAC). See
Role-Based Access Control (Overview) in System Administration Guide: Security Services for more information.
Guidelines for Using User Names, User IDs, and Group IDs
User names, UIDs, and GIDs should be unique within your organization, which might
span multiple domains.
Keep the following guidelines in mind when creating user or role names, UIDs,
and GIDs:
User names – They should contain from two to eight letters and numerals. The first character should be a letter. At least one character should be a lowercase letter.
Note - 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.
System accounts – Do not use any of the user names, UIDs, or GIDs that are contained in the default /etc/passwd and /etc/group files. Do not use the UIDs and GIDs, 0-99. These numbers are reserved for allocation by the Solaris Operating System and should not be used by anyone. Note that this restriction also applies to numbers not currently in use.
For example, gdm is the reserved user name and group name for the GNOME Display Manager daemon and should not be used for another user. For a complete listing of the default /etc/passwd and /etc/group entries, see Table 4-5 and Table 4-6.
The nobody and nobody4 accounts should never be used for running processes. These two accounts are reserved for use by NFS. Use of these accounts for running processes could lead to unexpected security risks. Processes that need to run as a non-root user should use the daemon or noaccess accounts.
System account configuration – The configuration of the default system accounts should never be changed. This includes changing the login shell of a system account that is currently locked. The only exception to this rule is the setting of a password and password aging parameters for the root account.
