Latest revision as of 15:09, 13 October 2011

In other languages: English (en) italiano (it) [edit]

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

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

Overall tracking bug

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

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.

Comments and Discussion

See Talk:Features/1000SystemAccounts

@@ Line 1: / Line 1: @@
+{{autolang|base=yes}}
 = 1000 System Accounts =
@@ Line 10: / Line 11: @@
 == Current status ==
 * Targeted release: [[Releases/16 | Fedora 16 ]]
-* Last updated: Jun 28 2011
+* Last updated: Sep 29 2011
-* Percentage of completion: 5%
+* 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; 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 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 <code>/etc/login.defs</code>.
@@ Line 29: / Line 30: @@
 |}
-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.
+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.
 <code>/etc/login.defs</code> is already the de-facto standard for configuring the system/user account boundary (used at least by <code>accountsservice</code>, <code>libsemanage</code>, <code>libuser</code> and of course <code>shadow-utils</code>), so we will formally codify it instead of inventing a new and incompatible configuration file.
@@ Line 35: / Line 36: @@
 Making the boundary configurable also allows some users to stay with the old boundary of 500, if they wish:
 * Because <code>/etc/login.defs</code> is <code>%config(noreplace)</code>, 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 <code>/etc/login.defs</code> in a kickstart <code>%pre</code> script; this is unpleasantly cumbersome (the <code>%pre</code> script 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.
+* 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 <code>/etc/login.defs</code> in a kickstart <code>%pre</code> script.
 == Benefit to Fedora ==
-* More space for system accounts, making sure we don't run out even on almost-"everything" installations
+* More space for system accounts in total, making it possible to try a larger-scale initiative to stop running system processes as root
-* Using the same ID allocation as upstream shadow(-utils), and some prominent Linux distributions.
+* 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 ==
+[https://bugzilla.redhat.com/show_bug.cgi?id=717109 Overall tracking bug]
 The allocation has already been changed in <code>shadow-utils</code>; the following packages (out of the "desktop" and "web server" installations available in Anaconda) need to be updated to read <code>/etc/login.defs</code>:
-* <code>PackageKit</code>
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717110 <code>PackageKit</code>]
-* <code>authconfig</code>
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717112 <code>authconfig</code>]
-* <code>firstboot</code>
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717113 <code>firstboot</code>]
-* <code>httpd</code>
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717115 <code>kde-settings</code>/<code>kdebase-workspace</code>]
-* <code>kde-settings</code>
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717122 <code>system-config-users</code>]
-* <code>system-config-users</code>
 and the following packages might be updated as well:
-* <code>audit</code> (documentation only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717111 <code>audit</code>] (documentation only)
-* <code>libuser</code> (documentation and unused API only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717116 <code>libuser</code>] (documentation and unused API only)
-* <code>openldap</code> (documentation only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717117 <code>openldap</code>] (documentation only)
-* <code>pam</code> (documentation only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717118 <code>pam</code>] (documentation only)
-* <code>sssd</code> (documentation only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717119 <code>sssd</code>] (documentation only)
-* <code>system-config-network</code> (unused code)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717120 <code>system-config-network</code>] (unused code)
-* <code>systemtap</code> (documentation only)
+* [https://bugzilla.redhat.com/show_bug.cgi?id=717123 <code>systemtap</code>] (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 easy to override the change for fresh installs is a possibility, but not committed to by anyone at this point.
+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 ==
@@ Line 76: / Line 80: @@
 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.
-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 difficult (only possible with kickstart and a <code>%pre</code> script).
+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 ==
@@ Line 82: / Line 86: @@
 == Contingency Plan ==
-At worst, we can always revert 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.
+Revert 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 they did in Fedora 15.
 == Documentation ==
@@ Line 88: / Line 92: @@
 == 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 <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 it 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.
 == Comments and Discussion ==
 * See [[Talk:Features/1000SystemAccounts]]
-[[Category:FeaturePageIncomplete]]
+[[Category:FeatureAcceptedF16]]
 <!-- When your feature page is completed and ready for review -->
 <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 <!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Search

Features/1000SystemAccounts: Difference between revisions