GLEP:27
Title:Portage Management of UIDs/GIDs
Version:1.1
Last-Modified:2004/05/29 14:31:58
Author:Mike Frysinger <vapier at gentoo.org>
Status:Draft
Type:Standards Track
Content-Type:text/x-rst
Created:29 May 2004
Post-History:29-May-2004

Contents

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

portage/profiles/accounts/
    user/<username>.xml
    group/<groupname>.xml
    accounts.xml

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 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 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...) are ever run.

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

References

[1]http://bugs.gentoo.org/show_bug.cgi?id=8634