User and Group Management

This is a BETA-quality proposal that is still being actively developed.

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.

The criteria defined above are not yet reflected in the rest of the document. I need to update it.