UID policy

Your friends and associates may know you as Joe or Mallory, but to the Unix system you're 813 ? and for good reason. Storing 813 only requires a couple of bytes. If you've been blessed with an understanding of the binary numbering system, then you're well aware that a byte (8 bits) can hold numbers from 0 to 255 (i.e., 256 different values). In two bytes, you can store numbers as high as 65,535. This means that, by using numeric identifiers, Unix is able to store in two bytes what might otherwise take twenty or so (and still have you truncating a lot of usernames). Unix systems store your identifier numerically not simply to save 18 or more bytes, but to save 18 or more bytes over and over and over again. Your numeric identifier is not only stored in the system's /etc/passwd file, it's stored with every file that you own (in the inode). Don't know the value of your UID? You can view your UID in several. The easiest way is to grep your username from the /etc/passwd file like so: % grep mallory /etc/passwd mallory:x:813:100:Mallory F. Stocker:/home/mallory:/bin/sh Another way is to long list your files, but add the -n (no interpret) option so that your UID is not looked up in the passwd file and translated into your username. % ls -ln * -rwxr-r-- 1 813 100 8123 Jul 2 myfile

Every file on a Unix system will have an owner and an associated UID. However, whenever you see a numeric identifier with a normal long listing, you'll know that the identifier doesn't correspond to any currently defined user or, at least, that the owner's entry has been removed from the /etc/passwd file or NIS/NIS+ map.

To locate files that are not associated with any currently defined user, you can look for numeric identifiers in long listings or search for them by using the find criteria "-nouser" as shown in this example:

% find ./* -nouser -ls

Thinking in Binary If you don't think in binary, then the list of numbers below can help you to see what a set bit (i.e., a 1) in any of the designated fields is worth. A set value in each of the first three bits (111) is worth 7, decimally speaking. bit value 1 1 2 2 3 4 4 8 5 16 6 32 7 64 8 128 9 256 10 512 11 1024 12 2048 13 4096 14 8192 15 16384 16 32768 17 65536 If each of the first 16 bits (right to left) in a binary number is set, then the value is 65,535 ? just one short of the value of the next leftmost bit.

Should Anyone Care About UIDs? Many Unix users move happily through their careers without ever knowing their UID. They may never see it or have any reason to care. Unix systems administrators normally do care. Many adamantly refuse to ever reuse a UID. Instead, they archive accounts or disable them by changing the password in the /etc/shadow file to one that is unknown to the user or is locked (e.g., *LK* in Solaris). In this way, no files left behind by these users will ever be of unknown parentage and an account can be returned to its original state if this is ever necessary. At the same time, unowned files can enter into a file system when tar files are extracted. Some sysadmins will hunt them down using a find command like that shown above.

UIDs can be arbitrarily assigned, but admins generally employ a method (usually sequentially) or tool to automate the assignment. Many Unix systems administrators select a range at which to begin allocating UIDs. UIDs below 100 are typically reserved for system accounts and services. User accounts start at 100, 500, or 1000. Given the number of UIDs available on most Unix systems (65,535 if not more than that), the likelihood of running out is very small.

The only disadvantage of locking accounts, instead of removing them, is that you may continue to collect email for these individuals. Should this become a problem, setting up a .forward file to the person's new electronic home or configuring Procmail to dump all the unwanted email into /dev/null is probably a much better idea than trying to keep the stale mail from consuming your disk space.