Get Gentoo!

GLEP 27: Portage Management of UIDs/GIDs

Author Mike Frysinger <[email protected]>
Type Standards Track
Status Deferred
Version 1
Created 2004-05-29
Last modified 2017-10-13
Posting history 2004-05-29, 2004-07-20
GLEP source glep-0027.rst

Status

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

Implementation not completed. Marked deferred by GLEP editor Michał Górny on 2017-10-13.

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

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/
    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. 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 hierarchy 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...) 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.