From Fedora Project Wiki
No edit summary
No edit summary
Line 5: Line 5:
Fondare su <code>login.defs</code> lo standard per la definizione delle autorizzazioni di spazio allocazione di UID/GID, ed allargare il limite tra account di sistema ed utente da 500 a 1000. ''(n.d.t. rivedere)''
Fondare su <code>login.defs</code> lo standard per la definizione delle autorizzazioni di spazio allocazione di UID/GID, ed allargare il limite tra account di sistema ed utente da 500 a 1000. ''(n.d.t. rivedere)''


== Owner ==
== Sviluppatore ==
* Name: [[User:Mitr| Miloslav Trmač]]
* Nome: [[User:Mitr| Miloslav Trmač]]
* Email: mitr@redhat.com
* Email: mitr@redhat.com


== Current status ==
== Descrizione dettagliata ==
* Targeted release: [[Releases/16 | Fedora 16 ]]
Lo spazio di allocazione UID/GID ("ID" da ora in poi), non è chiaramente definito in Fedora oltre ad essere strettamente codificato in molte applicazioni. Storicamente Fedora allocava 500 valori di ID per gli utenti di sistema; dato che gli attuali pacchetti Fedora allocano più di 270 account, maggiore spazio è richiesto per interrompere i processi di sistema come root, o per consentire di allocare staticamente più ID (da Fedora o da policy locali). Il valore di 500 devia anche dall'allocazione in shadow(-utils). 
* Last updated: Sep 29 2011
* Percentage of completion: 100% (6/6 required packages)


== Detailed Description ==
L'intento di questa feature, quindi, è allocare 1000 valori di ID per gli account di sistema. Un bel po' di applicazioni hanno codificato il valore 500 come limite; invece di sostituire questo valore con un valore fisso di 1000, tali applicazioni saranno modificate per leggere il limite dal file <code>/etc/login.defs</code>.
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>.
Il layout dell'ID cambierà come segue:


The ID layout will change as follows:
{|Intervallo !! Fedora &le;15 || Fedora &ge;16
{|
! Range !! Fedora &le;15 !! Fedora &ge;16
|-
|-
| Statically-allocated system accounts (<code>/usr/share/doc/setup/uidgid</code>) || 0-? || 0-200
| Account di sistema allocati staticamente (<code>/usr/share/doc/setup/uidgid</code>) || 0-? || 0-200
|-
| Account di sistema allocati dinamicamente (allocati in ordine decrescente) || ?-499 || 201-999
|-
|-
| Dynamically-allocated system accounts (allocated from higher to lower values) || ?-499 || 201-999
| Avvount utente || 500-60,000 || 1,000-60,000
|-
| 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.
Come sopra indicato, il limite tra account di sistema allocati staticamente e dinamicamente non è stato ben definito (si era pensato a 100, ma già in Fedora 15, gli UID statici allocati erano 173); il limite è ora esplicitamente definito, tramite SYS_[UG]ID_MIN), su 201, e poichè gli account di sistema dinamici sono allocati dai valori più alti, risulterà in futuro più semplice espandere lo spazio per gli account allocati staticamente.  


<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> è già lo standard di fatto per configurare il limite degli account di sistema/utente (usato se non altro già da  <code>accountsservice</code>, <code>libsemanage</code>, <code>libuser</code> e naturalmente da <code>shadow-utils</code>), quindi si procede alla sua codifica piuttosto che inventare un nuovo ed incompatibile file di configurazione.  


Making the boundary configurable also allows some users to stay with the old boundary of 500, if they wish:
Rendendo il limite configurabile, consente agli utenti di mentenere il precedente limite di 500, se desiderato:
* Because <code>/etc/login.defs</code> is <code>%config(noreplace)</code>, upgrades will retain the boundary value 500, and nothing should break.
* Poichè <code>/etc/login.defs</code> è <code>%config(noreplace)</code>, gli aggiornamenti mantengono il valore limite di 500, senza interruzioni;
* 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.
* Per nuove installazioni con impostazioni con UID allocati centralmente (p.e. usando LDAP), possono essere ugualmente configurati per usare il valore limite di 500 creando <code>/etc/login.defs</code> in un <code>%pre</code> script di kickstart.  


== Benefit to Fedora ==
== Vantaggi per Fedora ==
* More space for system accounts in total, making it possible to try a larger-scale initiative to stop running system processes as root
* Maggiore spazio per account di sistema, rendendo possibile di interrompere i processi di sistema come root, su scala maggiore
* Explicitly defined boundary between statically- and dynamically-allocated system accounts that reflects the actual allocation
* Esplicitamente definito il limite tra sistemi di account statici e dinamici, per riflettere l'attuale allocazione
* Enough space to allow expanding the statically-allocated space in the future
* Sufficiente spazio per consentire, in futuro, l'espansione dello spazio allocato staticamente
* Using the same ID allocation as upstream shadow(-utils), and some prominent Linux distributions (e.g. Debian, OpenSUSE)
* Usare la stessa llocazione di ID di shadow(-utils) di upstream, e di altre eminenti distribuzioni Linux (p.e. Debian, OpenSUSE)  


== Scope ==
== Esperienza utente ==
[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>:
* [https://bugzilla.redhat.com/show_bug.cgi?id=717110 <code>PackageKit</code>]
* [https://bugzilla.redhat.com/show_bug.cgi?id=717112 <code>authconfig</code>]
* [https://bugzilla.redhat.com/show_bug.cgi?id=717113 <code>firstboot</code>]
* [https://bugzilla.redhat.com/show_bug.cgi?id=717115 <code>kde-settings</code>/<code>kdebase-workspace</code>]
* [https://bugzilla.redhat.com/show_bug.cgi?id=717122 <code>system-config-users</code>]
 
and the following packages might be updated as well:
* [https://bugzilla.redhat.com/show_bug.cgi?id=717111 <code>audit</code>] (documentation only)
* [https://bugzilla.redhat.com/show_bug.cgi?id=717116 <code>libuser</code>] (documentation and unused API only)
* [https://bugzilla.redhat.com/show_bug.cgi?id=717117 <code>openldap</code>] (documentation only)
* [https://bugzilla.redhat.com/show_bug.cgi?id=717118 <code>pam</code>] (documentation only)
* [https://bugzilla.redhat.com/show_bug.cgi?id=717119 <code>sssd</code>] (documentation only)
* [https://bugzilla.redhat.com/show_bug.cgi?id=717120 <code>system-config-network</code>] (unused code)
* [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 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 <code>/etc/login.defs</code> similarly.
* Go through firstboot; review <code>/etc/passwd</code> and <code>/etc/group</code> to verify that the user account created in firstboot, and the system accounts created during installation follow the policy specified in <code>/etc/login.defs</code>.
* Start <code>gdm</code>, verify that all users and no system accounts are offered for login.  Verify that users can log in.
* Check <code>kdm</code> likewise.
* Set up httpd with suexec, verify that each user can run their own scripts through suexec.  (FIXME: expand this?)
* Start <code>system-config-users</code>, 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 <code>/etc/login.defs</code>.
* 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 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.
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 ==
== Documentazione ==
See "Scope".
 
== Contingency Plan ==
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 ==
<code>login.defs(5)</code>
<code>login.defs(5)</code>


== Release Notes ==
== Note di rilascio ==
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.
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.


== Comments and Discussion ==
* See [[Talk:Features/1000SystemAccounts]]


[[Category:FeatureAcceptedF16]]
[[Category:FeatureAcceptedF16]]  
<!-- When your feature page is completed and ready for review -->
[[Category: Italiano]]
<!-- 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 -->

Revision as of 14:31, 14 October 2011

1000 account di systema

Sommario

Fondare su login.defs lo standard per la definizione delle autorizzazioni di spazio allocazione di UID/GID, ed allargare il limite tra account di sistema ed utente da 500 a 1000. (n.d.t. rivedere)

Sviluppatore

Descrizione dettagliata

Lo spazio di allocazione UID/GID ("ID" da ora in poi), non è chiaramente definito in Fedora oltre ad essere strettamente codificato in molte applicazioni. Storicamente Fedora allocava 500 valori di ID per gli utenti di sistema; dato che gli attuali pacchetti Fedora allocano più di 270 account, maggiore spazio è richiesto per interrompere i processi di sistema come root, o per consentire di allocare staticamente più ID (da Fedora o da policy locali). Il valore di 500 devia anche dall'allocazione in shadow(-utils).

L'intento di questa feature, quindi, è allocare 1000 valori di ID per gli account di sistema. Un bel po' di applicazioni hanno codificato il valore 500 come limite; invece di sostituire questo valore con un valore fisso di 1000, tali applicazioni saranno modificate per leggere il limite dal file /etc/login.defs.

Il layout dell'ID cambierà come segue:

Account di sistema allocati staticamente (/usr/share/doc/setup/uidgid) 0-? 0-200
Account di sistema allocati dinamicamente (allocati in ordine decrescente) ?-499 201-999
Avvount utente 500-60,000 1,000-60,000

Come sopra indicato, il limite tra account di sistema allocati staticamente e dinamicamente non è stato ben definito (si era pensato a 100, ma già in Fedora 15, gli UID statici allocati erano 173); il limite è ora esplicitamente definito, tramite SYS_[UG]ID_MIN), su 201, e poichè gli account di sistema dinamici sono allocati dai valori più alti, risulterà in futuro più semplice espandere lo spazio per gli account allocati staticamente.

/etc/login.defs è già lo standard di fatto per configurare il limite degli account di sistema/utente (usato se non altro già da accountsservice, libsemanage, libuser e naturalmente da shadow-utils), quindi si procede alla sua codifica piuttosto che inventare un nuovo ed incompatibile file di configurazione.

Rendendo il limite configurabile, consente agli utenti di mentenere il precedente limite di 500, se desiderato:

  • Poichè /etc/login.defs è %config(noreplace), gli aggiornamenti mantengono il valore limite di 500, senza interruzioni;
  • Per nuove installazioni con impostazioni con UID allocati centralmente (p.e. usando LDAP), possono essere ugualmente configurati per usare il valore limite di 500 creando /etc/login.defs in un %pre script di kickstart.

Vantaggi per Fedora

  • Maggiore spazio per account di sistema, rendendo possibile di interrompere i processi di sistema come root, su scala maggiore
  • Esplicitamente definito il limite tra sistemi di account statici e dinamici, per riflettere l'attuale allocazione
  • Sufficiente spazio per consentire, in futuro, l'espansione dello spazio allocato staticamente
  • Usare la stessa llocazione di ID di shadow(-utils) di upstream, e di altre eminenti distribuzioni Linux (p.e. Debian, OpenSUSE)

Esperienza utente

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.

Documentazione

login.defs(5)

Note di rilascio

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.

Retrieved from "https://fedoraproject.org/w/index.php?title=Features/1000SystemAccounts/it&oldid=256921"