1000 System Accounts
login.defs as the authoritative definition of UID/GID space allocation, and move the boundary between system and user accounts from 500 to 1000.
- Name: Miloslav Trmač
- Email: email@example.com
- Targeted release: Fedora 16
- Last updated: Sep 29 2011
- Percentage of completion: 100% (6/6 required packages)
The UID/GID ("ID" from now on) space allocation is for Fedora is not clearly defined, and it is hard-coded in various applications. Historically Fedora has allocated 500 ID values for system users; given that current Fedora packages allocate over 270 accounts, more space would be required for a larger initiative to stop running system processes as root, or for allowing more statically-allocated IDs (whether by Fedora or site-local policy). The value 500 also deviates from the upstream allocation in shadow(-utils).
The intent of this feature is, therefore, to allocate 1000 ID values for system accounts. Quite a few applications have hard-coded the 500 value as a boundary; instead of replacing this with a hard-coded value of 1000, such applications will be modified to read the boundary from
The ID layout will change as follows:
|Range||Fedora ≤15||Fedora ≥16|
| Statically-allocated system accounts (
|Dynamically-allocated system accounts (allocated from higher to lower values)||?-499||201-999|
As shown above, the boundary between statically-allocated and dynamically-allocated system accounts has not been well-defined (it was supposed to be 100, but static UIDs up to 173 have been already allocated in Fedora 15); the boundary is now explicitly defined (using SYS_[UG]ID_MIN) to be 201, and because dynamically-allocated system accounts are allocated from higher values, it will be both easy and possible to expand the space for statically allocated system accounts in the future.
/etc/login.defs is already the de-facto standard for configuring the system/user account boundary (used at least by
libuser and of course
shadow-utils), so we will formally codify it instead of inventing a new and incompatible configuration file.
Making the boundary configurable also allows some users to stay with the old boundary of 500, if they wish:
%config(noreplace), upgrades will retain the boundary value 500, and nothing should break.
- New installations in setups where the UIDs are centrally allocated (e.g. using LDAP) from 500 could be likewise configured to use the boundary value 500 by creating
/etc/login.defsin a kickstart
Benefit to Fedora
- More space for system accounts in total, making it possible to try a larger-scale initiative to stop running system processes as root
- Explicitly defined boundary between statically- and dynamically-allocated system accounts that reflects the actual allocation
- Enough space to allow expanding the statically-allocated space in the future
- Using the same ID allocation as upstream shadow(-utils), and some prominent Linux distributions (e.g. Debian, OpenSUSE)
The allocation has already been changed in
shadow-utils; the following packages (out of the "desktop" and "web server" installations available in Anaconda) need to be updated to read
and the following packages might be updated as well:
libuser(documentation and unused API only)
I (mitr) didn't review the remaining Fedora packages (not in the "desktop" and "web server" installations in Anaconda), and I plan to ask their package maintainers on fedora-devel to review their/fix their own packages if possible.
Extending Anaconda's kickstart facilities to make it easier to override the change for fresh installs is a possibility, but not committed to by anyone at this point.
How To Test
Both on a clean installation and on an upgrade from Fedora 15:
- Verify that after a clean installation, UID_MIN is 1000 and after an upgrade, UID_MIN is 500; review the other values in
- Go through firstboot; review
/etc/groupto verify that the user account created in firstboot, and the system accounts created during installation follow the policy specified in
gdm, verify that all users and no system accounts are offered for login. Verify that users can log in.
- Set up httpd with suexec, verify that each user can run their own scripts through suexec. (FIXME: expand this?)
system-config-users, verify that user accounts and no system accounts are visible. Create a new user/group and verify that their ID allocation follow the policy specified in
- Verify other aspects of the system as possible, or other components that will be discovered to hard-code the "500" boundary, if any.
For users that don't use a site-wide ID allocation mechanism (e.g. LDAP), no visible impact is expected - neither on fresh installs nor on upgrades.
For users with a site-wide ID allocation mechanism (e.g. LDAP) that allocates user IDs >= 1000, no impact is expected either. If user IDs in the range 500-1000 are allocated, upgrades will work fine, but new installs that follow the site-wide policy will only be possible using kickstart.
/etc/login.defs settings to match Fedora 15; then all packages (whether unchanged from F15 or ported to use
/etc/login.defs) will work as they did in Fedora 15.
Fedora 16 changes the UID and GID allocation policy: user accounts now start from value 1000 instead of the previous value 500. This policy is now globally set in
login.defs(5) for more details. Upgrades from earlier Fedora releases will keep their configuration, starting user accounts from 500.
If you need to install a new system from scratch, while starting user accounts from 500 (to connect the system to a network with globally-defined UIDs), install using a kickstart script that places
/etc/login.defs on the file system before package installation starts.