What are the dangers of creating a normal user with UID < 500

rhelusers

What are the dangers of creating a normal user with UID < 500? Assuming the UID's are not duplicates of existing UID's, what could go wrong?

This is not something that I want to do, but something that I have seen and want to know why it shouldn't be done. In this example, it's on RHEL5.

Best Answer

I don't believe there is any inherent risk, this is something that is done simply to create separation between what are considered system accounts and user accounts. The practice of using numbers below 500, from my experience is a Redhat-ism, and really nothing more than that.

On Solaris I'd seen users being assigned numbers starting at 100 as well, only to years later discover that when merging 2 smaller departments' systems together causes a nightmare of sorts, since there were multiple users across the 2 departments that had the same UID/GID's assigned.

This is really the main risk/headache when assigning out the UIDs. Since the UID is what's ultimately written to the inode for a user's given files/directories, you don't want tot have to down the road be performing massive find's looking for files that are owned by UID 1234 and having to change them to 5678.

So by putting some thought into the selection of UIDs, administrators can avoid the headache down the road.

The use of 500 and above is just an attempt by Redhat (and other Unixes) to give themselves enough buffer that any system accounts that might need to be created won't get intermixed with UIDs that are assigned to users.

/etc/login.defs

Incidentally, the number 500 is driven by this setting in the config file, /etc/login.defs.

#
# Min/max values for automatic uid selection in useradd
#
UID_MIN           500
UID_MAX         60000

#
# Min/max values for automatic gid selection in groupadd
#
GID_MIN           500
GID_MAX         60000

You can change this to anything you want, if you'd like to override the default behavior by useradd/adduser commands.

Useradd man page

If you take a look at the useradd man page you'll notice this portion that discusses the default value for GID, but this comment is also applicable to UIDs too:

excerpt

-g, --gid GROUP
    The group name or number of the user´s initial login group. The group name 
    must exist. A group number must refer to an already existing group.

    If not specified, the behavior of useradd will depend on the USERGROUPS_ENAB 
    variable in /etc/login.defs. If this variable is set to yes 
    (or -U/--user-group is specified on the command line), a group will be 
    created for the user, with the same name as her loginname. If the variable 
    is set to no (or -N/--no-user-group is specified on the command line), 
    useradd will set the primary group of the new user to the value specified by 
    the GROUP variable in /etc/default/useradd, or 100 by default.

System accounts

One other things to take notice of in the useradd man page is this bit on system account generation.

excerpt

-r, --system
    Create a system account.

    System users will be created with no aging information in /etc/shadow, 
    and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX 
    range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their 
    GID counterparts for the creation of groups).

    Note that useradd will not create a home directory for such an user, 
    regardless of the default setting in /etc/login.defs (CREATE_HOME). You 
    have to specify the -m options if you want a home directory for a system 
    account to be created.

It's this method (useradd -r ...) that is often times used by scripting that's incorporated into the various package mangers, such as RPM, when a package is being installed. Scripting it this way allows the system to automatically select the next available UID/GID on a given system without risk of stepping on UIDs/GIDs already assigned to users of the system.

Related Question