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 <code>/etc/login.defs</code>, see <code>login.defs(5)</code> for more details. Upgrades from earlier Fedora releases will keep their configuration, starting user accounts from 500.

+

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 <code>/etc/login.defs</code> variables <code>GID_MIN</code> and <code>UID_MIN</code>, see <code>login.defs(5)</code> 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 <code>/etc/login.defs</code> on the file system before package installation starts.

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 <code>/etc/login.defs</code> on the file system before package installation starts.

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.defs is %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.defs in a kickstart %pre script.

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.

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.defs similarly.

Go through firstboot; review /etc/passwd and /etc/group to 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 kdm likewise.

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.

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.

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.