UNIX System Administration Handbook - Evi Nemeth [56]
It is never a good idea to have multiple accounts with UID 0. While it might seem convenient to have multiple root logins with different shells and/or passwords, this setup just creates more potential security holes and gives you multiple logins to secure. If people need to have alternate ways to log in as root, you are better off if they use a program like sudo.
See page 41 for more information about sudo.
Avoid recycling UIDs for as long as possible, even the UIDs of people that have left your organization and had their accounts permanently removed. This precaution prevents confusion if files are later restored from backups, in which users are identified by UID rather than by login name.
UIDs should be kept unique across your entire organization. That is, a particular UID should refer to the same login name and the same person on every machine. Failure to maintain distinct UIDs can result in security problems with systems such as NFS and can also result in confusion when a user moves from one workgroup to another.
See Chapter 17 for more information about NFS.
It can be hard to maintain unique UIDs when groups of machines are administered by different people or organizations. The problems are both technical and political. The best solution is to have a central database that contains a record for each user and enforces uniqueness. We use a home-grown database called Uniquid.3 A simpler scheme is to assign each group within an organization a range of UIDs and let each group manage its own set. This solution keeps the UID spaces separate (a requirement if you are going to use NFS to share filesystems) but does not address the parallel issue of unique login names.
Default GID number
Like a UID, a group ID number is a 16 or 32-bit integer which might be signed or unsigned. GID 0 is reserved for the group called “root” or “wheel”. GID 1 is usually the group “daemon”.
“wheel” was analogous to the root account in the TOPS-20 OS.
Groups are defined in the /etc/group file, with the GID field in /etc/passwd providing the effective GID at login time. Modern versions of UNIX allow a user to be in up to 16 groups at a time, so the effective GID is never used to determine access. The GID field in /etc/passwd is therefore something of a historical legacy, although its value is still included in the user’s group list.
On HP-UX, the user’s group list is initialized at login time from /etc/logingroup, not from /etc/group. We suggest that you make /etc/logingroup a symbolic link to /etc/group so that HP-UX behaves like most other systems with respect to its handling of multiple groups.
The only time at which the effective GID is of any relevance is during the creation of new files and directories. When BSD semantics are in effect, new files inherit the GID of their parent directory. When BSD semantics are not in effect, new files are assigned the user’s current effective GID; to change this GID, users run the newgrp command.
Most operating systems do not default to the BSD semantics, but they support BSD semantics as an option, either through a grpid option to mount or through use of the setgid bit (02000) on individual directories. BSD semantics are always in effect on FreeBSD, which lacks the newgrp command (this is considered a feature).
GECOS field4
The GECOS field has no well-defined syntax. It originally held the login information needed to transfer batch jobs from UNIX systems at Bell Labs to a mainframe running GECOS; these days, only the name remains.
The GECOS field is commonly used to record personal information about each user. A few programs will expand an ‘&’ in the GECOS field to the user’s login name, which saves a bit of typing. Both finger and sendmail perform this expansion, but many programs do not. It’s best not to rely on this feature.
Although you can use any formatting conventions you like, finger interprets comma-separated GECOS entries in the following order:
• Full name (often the only field used)
• Office number and building
• Office telephone