FLOP:User and Group Management

Portage User and Group Management Proposal

This page is intended to describe an implementation for user and group management in Portage, following the spirit (but not exact implementation) of GLEP 27 and taking the good ideas from Exheres, with my own take on things to work better with Gentoo/Funtoo's cascading profiles and multiple OS support. I am open to input and involvement from Zac Medico too, and other interested parties.

This missing functionality goes all the way back to Gentoo Bug 8634 So it's time to get this fixed.

Goals

The current system of adding users uses the Portage enewuser and enewgroup commands, which appear within individual ebuilds. In addition, core system accounts are defined within the sys-apps/baselayout ebuild. This system functions, but has a number of limitations:

• Application user and group IDs are hard-coded cannot be assigned dynamically based on policy. This creates a number of sub-problems:
  • Third-party overlays cannot easily add their own application users and groups and avoid conflicts.
  • System administrators have no control over user and group ID assignment.
  • User and group IDs in Gentoo Linux are "rigid" and are not able to cleanly adapt to different local user and group policies, and future changes.
• There is no mechanism to disable or modify the behavior of the automatic creation of application users and groups.
  • This can create problems for LDAP and NFS/NIS systems where groups are defined globally and resolved through other mechanisms.
• Default system users and groups are defined in the sys-apps/baselayout ebuild, which means there is no mechanism for profiles to easily extend or modify the set of system users and groups.
• There is no easy way to identify users and groups that may no longer be required by the system (Note: stray files could still use these users/groups)

The goal of this proposal is to address these deficiencies, while recognizing these truths about user and group accounts:

• system accounts are fundamentally different from application accounts that may be required by ebuilds.
  • It should be convenient for ebuilds to define application accounts without having to modify profiles.
  • Additionally, it can be useful, but is not absolutely necessary, to streamline the creation, maintenance and modification of system accounts that are now created in sys-apps/baselayout.

Phase 1 Implementation

The scope of the user/group improvements has become very ambitious. This, in turn, has led to a delay in implementation of important features. Therefore, this proposal organizes new user and group functionality into phases. Critical functionality should be added first. Then more complex and sophisticated mechanisms can be defined to manage users and groups in future phases, and can be integrated into Portage gradually.

Disable User/Group Creation via FEATURES

This section describes a mechanism to disable automatic user and group creation by ebuilds.

The proposed mechanism is it use a new FEATURES variable called auto-accounts, which is to be enabled by default.

Initially, this will be implemented with patches to eutils.eclass and Portage. The suggested implementation is to have enewuser and enewgroup abort with an error when auto-accounts is not set in FEATURES and the user/group requested does not exist. This error must display the user/group information passed to enewuser and enewgroup so that the administrator can manually create the accounts. The existing egetent function should be sufficient for determining if the user or group exists.

Backwards Compatibility

It is suggested that as part of this implementation, Portage exports SUPPORTED_FEATURES as an environment variable, and then eutils.eclass can enable the new functionality only if auto-accounts is in SUPPORTED_FEATURES. If it is not, then eutils.eclass should follow the legacy behavior of unconditionally creating users and groups. This will ensure that eutils.eclass is backwards-compatible with versions of Portage that do not support this functionality.

Implementation Timeframe and Benefits

It is estimated that a production-quality version of this functionality could be implemented within a week. There are no significant technical hurdles. It will provide an immediate benefit to systems that use NIS, LDAP or other mechanisms for user and group management.

This directly solves the following problems:

• There is no mechanism to disable or modify the behavior of the automatic creation of application users and groups.
  • This can create problems for LDAP and NFS/NIS systems where groups are defined globally and resolved through other mechanisms.

It also partially solves these problems:

• • User and group IDs in Gentoo Linux are "rigid" and are not able to cleanly adapt to different local user and group policies, and future changes.

This is because the administrator can now manually create users and groups as a work-around and configure them as he or she pleases.