user ID less than 1000 on CentOS 7

Question

I am now installing a new Linux server with CentOS-7. Before, I used CentOS-6 on all machines and used uid = 555 for my account. However, on CentOS-7, it seems that uid <= 999 are reserved for system (accoding to some articles on the net). For testing purpose, I have tried to make an account with uid = 555, such that

# useradd -u 555 {my-login-name}

Then, a new account was created even on CentOS-7 with no warning etc from the command.

I understand that uid <= 999 is "reserved for system", but practically speaking, is there any serious problem to keep using the above uid (555)? Or, considering the future possibility that a new service may use 555, should I avoid using it? I appreciate any advice for this!

---

EDIT

The /etc/login.defs on my new machine (Centos-7) shows

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

while that on my old machine (Centos-6) is

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

so having different UID_MIN. Also, /etc/passwd on my new machine looks like

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
adm:x:3:4:adm:/var/adm:/sbin/nologin
lp:x:4:7:lp:/var/spool/lpd:/sbin/nologin
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:/sbin/nologin
operator:x:11:0:operator:/root:/sbin/nologin
games:x:12:100:games:/usr/games:/sbin/nologin
ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin
nobody:x:99:99:Nobody:/:/sbin/nologin
pegasus:x:66:65:tog-pegasus OpenPegasus WBEM/CIM services:/var/lib/Pegasus:/sbin/nologin
ods:x:999:998:softhsm private keys owner:/var/lib/softhsm:/sbin/nologin
systemd-bus-proxy:x:998:996:systemd Bus Proxy:/:/sbin/nologin
systemd-network:x:192:192:systemd Network Management:/:/sbin/nologin
dbus:x:81:81:System message bus:/:/sbin/nologin
polkitd:x:997:995:User for polkitd:/:/sbin/nologin
apache:x:48:48:Apache:/usr/share/httpd:/sbin/nologin
tss:x:59:59:Account used by the trousers package to sandbox the tcsd daemon:/dev/null:/sbin/nologin
colord:x:996:993:User for colord:/var/lib/colord:/sbin/nologin
abrt:x:173:173::/etc/abrt:/sbin/nologin
unbound:x:995:992:Unbound DNS resolver:/etc/unbound:/sbin/nologin
usbmuxd:x:113:113:usbmuxd user:/:/sbin/nologin
libstoragemgmt:x:994:991:daemon account for libstoragemgmt:/var/run/lsm:/sbin/nologin
saslauth:x:993:76:Saslauthd user:/run/saslauthd:/sbin/nologin
dirsrv:x:389:389:389-ds-base:/usr/share/dirsrv:/sbin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin
amandabackup:x:33:6:Amanda user:/var/lib/amanda:/bin/bash
pcp:x:388:388:Performance Co-Pilot:/var/lib/pcp:/sbin/nologin
geoclue:x:387:386:User for geoclue:/var/lib/geoclue:/sbin/nologin
setroubleshoot:x:386:385::/var/lib/setroubleshoot:/sbin/nologin
postfix:x:89:89::/var/spool/postfix:/sbin/nologin
memcached:x:385:384:Memcached daemon:/run/memcached:/sbin/nologin
rtkit:x:172:172:RealtimeKit:/proc:/sbin/nologin
mysql:x:27:27:MariaDB Server:/var/lib/mysql:/sbin/nologin
qemu:x:107:107:qemu user:/:/sbin/nologin
radvd:x:75:75:radvd user:/:/sbin/nologin
chrony:x:384:383::/var/lib/chrony:/sbin/nologin
ntp:x:38:38::/etc/ntp:/sbin/nologin
sssd:x:383:382:User for sssd:/:/sbin/nologin
rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
pulse:x:171:171:PulseAudio System Daemon:/var/run/pulse:/sbin/nologin
hsqldb:x:96:96::/var/lib/hsqldb:/sbin/nologin
tomcat:x:91:91:Apache Tomcat:/usr/share/tomcat:/sbin/nologin
pkiuser:x:17:17:Certificate System:/usr/share/pki:/sbin/nologin
gdm:x:42:42::/var/lib/gdm:/sbin/nologin
gnome-initial-setup:x:382:379::/run/gnome-initial-setup/:/sbin/nologin
avahi:x:70:70:Avahi mDNS/DNS-SD Stack:/var/run/avahi-daemon:/sbin/nologin
sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
tcpdump:x:72:72::/:/sbin/nologin
oprofile:x:16:16:Special user account to be used by OProfile:/var/lib/oprofile:/sbin/nologin

From the uid shown above, it seems to me that new services use uid from 999(ods) -> 998 (systemd-bus-proxy) -> 997(polkitd) -> ... -> 993(saslauth). So, if this scheme is followed by other new services as well (in future), there may be little risk for using 555 (for me). FYI, other users (except me) already have uid >= 1000, so no problem for them. But I've been using 555 for other machines (including Mac), so still wondering if it's better to use uid >= 1000 from now on.

Answer 1

Well, i'm glad you ask, because it's an interesting question.

As per Wikipedia:

The Linux Standard Base Core Specification specifies that UID values in the range 0 to 99 should be statically allocated by the system, and shall not be created by applications, while UIDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts.[4]

On FreeBSD, porters who need a UID for their package can pick a free one from the range 50 to 999 and then register the static allocation.[5][6]

Some POSIX systems allocate UIDs for new users starting from 500 (OS X, Red Hat Enterprise Linux), others start at 1000 (openSUSE, Debian[7]). On many Linux systems, these ranges are specified in /etc/login.defs, for useradd and similar tools.

Central UID allocations in enterprise networks (e.g., via LDAP and NFS servers) may limit themselves to using only UID numbers well above 1000, to avoid potential conflicts with UIDs locally allocated on client computers. NFSv4 can help avoid numeric identifier collisions, by identifying users (and groups) in protocol packets using "user@domain" names rather than integer numbers, at the expense of additional translation steps.

Source: https://en.wikipedia.org/wiki/User_identifier

So what i get from this is:
- Less than 50 to 99 == high risks of conflicts with system applications
- Less than 499 = risk of conflicts with programs
- Less than 1000 = small risk of conflicts with programs
- For network UID systems, you want to use only high numbers

In the worst case, still from my understanding, you might have a program or user or group, that is allowed to interact with files or process from other programs... I guess it's not a big deal on most small servers, but might become an important security breach on bigger systems.

Answer 2

From https://systemd.io/UIDS-GIDS/

Distributions generally split the available UID range in two:

1…999 → System users. These are users that do not map to actual “human” users, but are used as security identities for system daemons, to implement privilege separation and run system daemons with minimal privileges.

1000…65533 and 65536…4294967294 → Everything else, i.e. regular (human) users.

...

Note for both allocation ranges: when an UID allocation takes place NSS is checked for collisions first, and a different UID is picked if an entry is found