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.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 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
“[email protected]” 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.
Method 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
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0