Features/1000SystemAccounts
From FedoraProject
Contents |
1000 System Accounts
Summary
Standardize on login.defs as the authoritative definition of UID/GID space allocation, and move the boundary between system and user accounts from 500 to 1000.
Owner
- Name: Miloslav Trmač
- Email: mitr@redhat.com
Current status
- Targeted release: Fedora 16
- Last updated: Sep 29 2011
- Percentage of completion: 100% (6/6 required packages)
Detailed Description
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 /etc/login.defs.
The ID layout will change as follows:
| Range | Fedora ≤15 | Fedora ≥16 |
|---|---|---|
Statically-allocated system accounts (/usr/share/doc/setup/uidgid) | 0-? | 0-200 |
| Dynamically-allocated system accounts (allocated from higher to lower values) | ?-499 | 201-999 |
| User accounts | 500-60,000 | 1,000-60,000 |
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 accountsservice, libsemanage, 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:
- Because
/etc/login.defsis%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%prescript.
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)
Scope
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 /etc/login.defs:
and the following packages might be updated as well:
-
audit(documentation only) -
libuser(documentation and unused API only) -
openldap(documentation only) -
pam(documentation only) -
sssd(documentation only) -
system-config-network(unused code) -
systemtap(documentation 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
/etc/login.defssimilarly. - Go through firstboot; review
/etc/passwdand/etc/groupto verify that the user account created in firstboot, and the system accounts created during installation follow the policy specified in/etc/login.defs. - Start
gdm, verify that all users and no system accounts are offered for login. Verify that users can log in. - Check
kdmlikewise. - Set up httpd with suexec, verify that each user can run their own scripts through suexec. (FIXME: expand this?)
- Start
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/etc/login.defs. - Verify other aspects of the system as possible, or other components that will be discovered to hard-code the "500" boundary, if any.
User Experience
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.
Dependencies
See "Scope".
Contingency Plan
Revert the /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.
Documentation
login.defs(5)
Release Notes
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 /etc/login.defs variables GID_MIN and UID_MIN, see 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.
