From Fedora Project Wiki
No edit summary
 
(22 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{autolang|base=yes}}
= 1000 System Accounts =
= 1000 System Accounts =


Line 10: Line 11:
== Current status ==
== Current status ==
* Targeted release: [[Releases/16 | Fedora 16 ]]  
* 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 ==
== 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>.
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.
<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:
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.
* 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 ==
== 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 ==
== 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>:
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:
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.
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 ==
== 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.
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 ==
== Dependencies ==
Line 82: Line 86:


== Contingency Plan ==
== 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 ==
== Documentation ==
Line 88: Line 92:


== Release Notes ==
== 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 ==
== Comments and Discussion ==
* See [[Talk:Features/1000SystemAccounts]]
* See [[Talk:Features/1000SystemAccounts]]


[[Category:FeaturePageIncomplete]]
[[Category:FeatureAcceptedF16]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- 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-->
<!-- 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 -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 15:09, 13 October 2011

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

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:

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