--- xml/htdocs/proj/en/glep/glep-0027.html 2004/07/20 18:21:20 1.2 +++ 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 - + -
- +
@@ -33,17 +275,17 @@ - + - + - + - + @@ -52,8 +294,8 @@
Title:Portage Management of UIDs/GIDs
Version:1.3
Version:1.5
Last-Modified:2004/07/20 18:19:27
Last-Modified:2005/09/18 20:48:23
Author:Mike Frysinger <vapier at gentoo.org>
Status:Draft
Status:Approved
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

-

A new directory will need to be added to the rsync tree to store the -files that define the default values for new accounts.

+
+

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/accounts/
-    user/<username>.xml
-    group/<groupname>.xml
-    accounts.xml
+portage/profiles/base/accounts/
+    user/<username>
+    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.xml. Each -username.xml 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 tagged as such. Each groupname.xml will -follow similar guidelines. The accounts.xml 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/accounts/ that mimics -the heirarchy found in the portage tree. When portage attempts to add a -new user, it will first check /etc/portage/accounts/user/<username>.xml. -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.

- - - +