|Line 82:||Line 82:|
== Contingency Plan ==
== Contingency Plan ==
the <code>/etc/login.defs</code> settings to match Fedora 15; then all packages (whether unchanged from F15 or ported to use <code>/etc/login.defs</code>) will work as in Fedora 15.
== Documentation ==
== Documentation ==
Revision as of 03:51, 28 June 2011
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: firstname.lastname@example.org
- Targeted release: Fedora 16
- Last updated: Jun 28 2011
- Percentage of completion: 5%
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; this is sufficient for single-user installations, but large multi-user setups are at risk of running out of the ID space (all Fedora packages already create about FIXME users); it 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.
/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
%prescript; this is unpleasantly cumbersome (the
%prescript would have to create all partitions to be able to create the file), but possible - and it could probably be made easier by adding a new script type to anaconda.
Benefit to Fedora
- More space for system accounts, making sure we don't run out even on almost-"everything" installations
- Using the same ID allocation as upstream shadow(-utils), and some prominent Linux distributions.
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 easy 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 be somewhat difficult (only possible with kickstart and a
/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 it 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.