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.
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.
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.
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.
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.
There is no real danger. The kernel doesn't care about user ID values except 0. Most administration tools do not care either — very few parts of the system make a difference between system users and human users.
System users tend to have dedicated groups, so this isn't likely to create accounts belonging to more groups than they should.
Some distributions reserve the range 1–499 (Red Hat and relatives) or 1–999 (Debian and relatives) for system users, including users allocated when installing a package containing a system service that requires a dedicated user. Debian's convention is that the range 1–99 is statically allocated (so creating a human user in that range is a very bad idea as it may clash with a system user) while the range 100–999 is dynamically allocated (so creating a human user in that range is harmless, since any new system user will pick a free user ID).
You may run into minor inconveniences, such as display managers not offering users with UIDs below the threshold in their list.
The main danger for an isolated machine is that you're likely to confuse your fellow system administrators. For a machine in a network where user IDs are shared, you may run into conflicts with other machines where these users have the same user ID as a system user. In networks with shared user IDs, it is best to stick to the range 1000–65533 or even 10000–65533 for human users.
From the kernel's perspective there is only one special user: UID 0. Splitting ranges of UIDs for administrative reasons makes your life simpler. The common ranges are vendor, system, local, global.
The vendor users are installed during initial install of the system and are staticly managed by the vendor. system users are installed per machine depending on what packages are installed. most user add/delete utilites have a range limit to handle these separately. local users are regular users and assigned per machine. global users are assigned by a central database, but are regular users. using UID ranges prevents conflicts between these diffrent groups. where these cutoffs are can vary but is usually configurable.
There are no inherent dangers in doing this. If you create a user with UID 499, they are not going to have any extra privs. The reason that it is suggested not to is simply because the UIDs are typically reserved for system users. The problem that one may encounter in creating such a UID is when some system service expects the UID to be available. It's kind of like creating a new service that runs on a well known port--there's no problem with it necessarily, but it's not good practice and can cause issues further down the road when you are setting up sshd, ftpd, etc.
That said, I've seen many systems where users were created with UID < 500 without issue. However, as the user base grows and there are now thousands of users, it can become difficult to differentiate between user accounts and system accounts. Following the rule of no UID < 500, it is very easy. So, it is a nice way to organize accounts as well.
PAM configuration files often make decisions based on the UID. e.g. lines from RHEL 7.7:
/etc/pam.d/password-auth:auth requisite pam_succeed_if.so uid >= 1000 quiet_success
/etc/pam.d/password-auth:account sufficient pam_succeed_if.so uid < 1000 quiet
So system accounts are granted special privileges which you may not want for a normal user account. Also users with uid less than 1000 may find they cannot login.
On RHEL when you log off, systemd kills all your processes you left running on system. It also deletes all shared memory segments you created during your session. Unless you're system user (your uid < 1000).
It makes a big difference when you run Oracle database as system vs. non-system user.
