--- xml/htdocs/proj/en/glep/glep-0027.html 2005/09/18 20:48:23 1.4 +++ xml/htdocs/proj/en/glep/glep-0027.html 2006/10/10 20:25:14 1.5 @@ -8,9 +8,252 @@ --> - + GLEP 27 -- Portage Management of UIDs/GIDs - + @@ -32,9 +275,9 @@ - + - + @@ -42,7 +285,7 @@ - + @@ -51,8 +294,8 @@
Title:Portage Management of UIDs/GIDs
Version:1.4
Version:1.5
Last-Modified:2005/09/15 02:39:54
Last-Modified:2005/09/18 20:48:23
Author:Mike Frysinger <vapier at gentoo.org>
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:29 May 2004

-
-

Contents

+
+

Contents

-
-

Status

+
+

Status

This GLEP was approved as-is on 14-Jun-2004.

-
-

Abstract

-

The current handling of users and groups in the portage system lacks -policy and a decent API. We need an API that is both simple for +

+

Abstract

+

The current handling of users and groups in the portage system lacks +policy and a decent API. We need an API that is both simple for developers and end users.

-
-

Motivation

-

Currently the policy is left up to respective ebuild maintainers to -choose the username, id, shell settings, etc... and to have them added -in the right place at the right time in the right way. When the -addition of users was found to often times have broken logic, the -enewuser and enewgroup functions were designed to remove all the -details. However, these functions still suffer from some fundamental -problems. First, there is no local customization. Second, maintainers -still use the functions improperly (binary packages have suffered the -most thus far). Third, the functions are not portable across non-linux -systems and not friendly to cross compiling or other exotic setups. -There are other reasons, but these listed few are enough to warrant +

+

Motivation

+

Currently the policy is left up to respective ebuild maintainers to +choose the username, id, shell settings, etc... and to have them added +in the right place at the right time in the right way. When the +addition of users was found to often times have broken logic, the +enewuser and enewgroup functions were designed to remove all the +details. However, these functions still suffer from some fundamental +problems. First, there is no local customization. Second, maintainers +still use the functions improperly (binary packages have suffered the +most thus far). Third, the functions are not portable across non-linux +systems and not friendly to cross compiling or other exotic setups. +There are other reasons, but these listed few are enough to warrant change.

-
-

Specification

-
-

Portage Structure

-
-

Defining Accounts

-

New directories will need to be added to the rsync tree to store the files -that define the default values for new accounts. They will be stored on a -per-profile basis, that way sub-profiles may easily override parent profiles. -The default location will be the base profile since all other profiles inherit +

+

Specification

+
+

Portage Structure

+
+

Defining Accounts

+

New directories will need to be added to the rsync tree to store the files +that define the default values for new accounts. They will be stored on a +per-profile basis, that way sub-profiles may easily override parent profiles. +The default location will be the base profile since all other profiles inherit from there.

 portage/profiles/base/accounts/
@@ -123,85 +366,85 @@
     group/<groupname>
     accounts
 
-

The files are named with the respective user/group name since they need -to be unique in their respective domains. For example, the file -detailing the ntp user would be located accounts/user/ntp. Each -username file will detail the required information about each user. -Certain account features that exist on one class of systems (Linux) but -not on others (*BSD) can be redefined in their respective subprofiles. Each -groupname will follow similar guidelines. The accounts file will be used to -describe global account defaults such as the default range of 'valid system' -ids. For example, if the UID 123 is already used on a system, but the ntp -user defaults to '123', we obviously cannot just duplicate it. So we -would select the next available UID on the system based upon the range +

The files are named with the respective user/group name since they need +to be unique in their respective domains. For example, the file +detailing the ntp user would be located accounts/user/ntp. Each +username file will detail the required information about each user. +Certain account features that exist on one class of systems (Linux) but +not on others (*BSD) can be redefined in their respective subprofiles. Each +groupname will follow similar guidelines. The accounts file will be used to +describe global account defaults such as the default range of 'valid system' +ids. For example, if the UID 123 is already used on a system, but the ntp +user defaults to '123', we obviously cannot just duplicate it. So we +would select the next available UID on the system based upon the range defined here.

-
-

Local Overrides

-

Following the tried and true style of custom local portage files being -found in /etc/portage, this new system will follow the same. Users can -setup their own directory heirarchy in /etc/portage/profile/accounts/ that -mimics the heirarchy found in the portage tree. When portage attempts to add -a new user, it will first check /etc/portage/profile/accounts/user/<username>. -If it does not exist, it will simply use the default definition in the +

+

Local Overrides

+

Following the tried and true style of custom local portage files being +found in /etc/portage, this new system will follow the same. Users can +setup their own directory heirarchy in /etc/portage/profile/accounts/ that +mimics the heirarchy found in the portage tree. When portage attempts to add +a new user, it will first check /etc/portage/profile/accounts/user/<username>. +If it does not exist, it will simply use the default definition in the portage tree.

-
-

Developer Interface

-
-

EUSERS + EGROUPS

-

Ebuilds that wish to add users or groups to the system must set these -variables. They are both space delimited lists that tells portage what -users/groups must be added to the system before emerging the ebuild. The -maintainer of the ebuild can assume the users/groups they have listed -exist before the functions in the ebuild (pkg_setup, src_install, etc...) +

+

Developer Interface

+
+

EUSERS + EGROUPS

+

Ebuilds that wish to add users or groups to the system must set these +variables. They are both space delimited lists that tells portage what +users/groups must be added to the system before emerging the ebuild. The +maintainer of the ebuild can assume the users/groups they have listed +exist before the functions in the ebuild (pkg_setup, src_install, etc...) are ever run.

-
-

Defining Accounts

-

Any developer is free to add users/groups in their ebuilds provided they +

+

Defining Accounts

+

Any developer is free to add users/groups in their ebuilds provided they create the required account definition files.

-
-

User Interface

-
-

users-update

-

When this script is run, all the users/groups that have been added by -portage to the system will be shown along with the packages that have -added said users/groups. Here they can delete accounts that are no longer -required by the currently installed packages (and optionally run a -script that will try to locate all files on the system that may still be +

+

User Interface

+
+

users-update

+

When this script is run, all the users/groups that have been added by +portage to the system will be shown along with the packages that have +added said users/groups. Here they can delete accounts that are no longer +required by the currently installed packages (and optionally run a +script that will try to locate all files on the system that may still be owned by the account).

-
-

FEATURES=noautoaccts

-

This is for the people who never want portage creating accounts for them. -When portage needs to add an account to the system but "noautoaccts" is -in FEATURES, portage will abort with a message instructing the user to -add the accounts that are listed in EUSERS and EGROUPS. This is +

+

FEATURES=noautoaccts

+

This is for the people who never want portage creating accounts for them. +When portage needs to add an account to the system but "noautoaccts" is +in FEATURES, portage will abort with a message instructing the user to +add the accounts that are listed in EUSERS and EGROUPS. This is obviously a required step before the package will be emerged.

-
-

Rationale

-

Developers no longer have to worry about how to properly add users/groups -to systems and worry about whether or not their code will work on all -systems (LDAP vs local shadow vs cross compile vs etc...). Users can -easily override the defaults Gentoo has before dictated. The default -passwd and group database can once again be trimmed down to the barest of +

+

Rationale

+

Developers no longer have to worry about how to properly add users/groups +to systems and worry about whether or not their code will work on all +systems (LDAP vs local shadow vs cross compile vs etc...). Users can +easily override the defaults Gentoo has before dictated. The default +passwd and group database can once again be trimmed down to the barest of accounts.

-
-

Backwards Compatibility

-

Handled in similar fashion as other portage rollouts. When using the new -account system, add a DEPEND for the required version of portage to the +

+

Backwards Compatibility

+

Handled in similar fashion as other portage rollouts. When using the new +account system, add a DEPEND for the required version of portage to the ebuild.

-
-

References

+
+

References

@@ -209,8 +452,8 @@
-