Sun Microsystems Logo
Products & Services
 
Support & Training
 
 

Previous Previous     Contents     Index     Next Next

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.

Table 4-2 Interoperability Issues for UIDs or GIDs Over 60000

Category

Product or Command

Issues or Cautions

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, but 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-3 Large UID or GID Limitation Summary

UID or GID

Limitations

60003 or greater

  • Users in this category logging into 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 see UIDs in this category truncated to 16 bits, creating possible security problems.

  • Users in this category using 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.

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

  • x86 based systems: Users in this category running SVR3-compatible applications will probably see EOVERFLOW return codes from system calls.

  • x86 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.

100000 or greater

  • The ps -l command displays a maximum five-digit UID so 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 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 in this category using the ar command have their UIDs and GIDs set to nobody in the archive.

2097152 or greater

  • Users in this category using the tar command, the cpio -H ustar command, or the pax -x tar command have their UIDs and GIDs set to nobody.

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, which is a combination of six to eight letters, numbers, or special characters.

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 12/02 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.

Previous Previous     Contents     Index     Next Next