en/glep/glep-0027.txt

GLEP: 27
Title: Portage Management of UIDs/GIDs
Version: $Revision: 1.1 $
Last-Modified: $Date: 2004/05/29 14:31:58 $
Author: Mike Frysinger <vapier@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 29 May 2004
Post-History: 29-May-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 
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
==========

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


Copyright
=========

This document has been placed in the public domain.
1	GLEP: 27
2	Title: Portage Management of UIDs/GIDs
3	Version: $Revision: 1.1 $
4	Last-Modified: $Date: 2004/05/29 14:31:58 $
5	Author: Mike Frysinger <vapier@gentoo.org>
6	Status: Draft
7	Type: Standards Track
8	Content-Type: text/x-rst
9	Created: 29 May 2004
10	Post-History: 29-May-2004
11
12
13	Abstract
14	========
15
16	The current handling of users and groups in the portage system lacks
17	policy and a decent API. We need an API that is both simple for
18	developers and end users.
19
20
21	Motivation
22	==========
23
24	Currently the policy is left up to respective ebuild maintainers to
25	choose the username, id, shell settings, etc... and to have them added
26	in the right place at the right time in the right way. When the
27	addition of users was found to often times have broken logic, the
28	enewuser and enewgroup functions were designed to remove all the
29	details. However, these functions still suffer from some fundamental
30	problems. First, there is no local customization. Second, maintainers
31	still use the functions improperly (binary packages have suffered the
32	most thus far). Third, the functions are not portable across non-linux
33	systems and not friendly to cross compiling or other exotic setups.
34	There are other reasons, but these listed few are enough to warrant
35	change.
36
37
38	Specification
39	=============
40
41
42	Portage Structure
43	-----------------
44
45
46	Defining Accounts
47	'''''''''''''''''
48
49
50	A new directory will need to be added to the rsync tree to store the
51	files that define the default values for new accounts.
52
53	::
54
55	portage/profiles/accounts/
56	user/<username>.xml
57	group/<groupname>.xml
58	accounts.xml
59
60	The files are named with the respective user/group name since they need
61	to be unique in their respective domains. For example, the file
62	detailing the ntp user would be located accounts/user/ntp.xml. Each
63	username.xml file will detail the required information about each user.
64	Certain account features that exist on one class of systems (Linux) but
65	not on others (\*BSD) can be tagged as such. Each groupname.xml will
66	follow similar guidelines. The accounts.xml will be used to describe
67	global account defaults such as the default range of 'valid system' ids.
68	For example, if the UID 123 is already used on a system, but the ntp
69	user defaults to '123', we obviously cannot just duplicate it. So we
70	would select the next available UID on the system based upon the range
71	defined here.
72
73
74	Local Overrides
75	'''''''''''''''
76
77	Following the tried and true style of custom local portage files being
78	found in /etc/portage, this new system will follow the same. Users can
79	setup their own directory heirarchy in /etc/portage/accounts/ that mimics
80	the heirarchy found in the portage tree. When portage attempts to add a
81	new user, it will first check /etc/portage/accounts/user/<username>.xml.
82	If it does not exist, it will simply use the default definition in the
83	portage tree.
84
85
86	Developer Interface
87	-------------------
88
89
90	EUSERS + EGROUPS
91	''''''''''''''''
92
93	Ebuilds that wish to add users or groups to the system must set these
94	variables. They are both space delimited lists that tells portage what
95	users/groups must be added to the system before emerging the ebuild. The
96	maintainer of the ebuild can assume the users/groups they have listed
97	exist before the functions in the ebuild (pkg_setup, src_install, etc...)
98	are ever run.
99
100
101	Defining Accounts
102	'''''''''''''''''
103
104	Any developer is free to add users/groups in their ebuilds provided they
105	create the required account definition files.
106
107
108	User Interface
109	--------------
110
111
112	users-update
113	''''''''''''
114
115	When this script is run, all the users/groups that have been added by
116	portage to the system will be shown along with the packages that have
117	added said users/groups. Here they can delete accounts that are no longer
118	required by the currently installed packages (and optionally run a
119	script that will try to locate all files on the system that may still be
120	owned by the account).
121
122
123	FEATURES=noautoaccts
124	''''''''''''''''''''
125
126	This is for the people who never want portage creating accounts for them.
127	When portage needs to add an account to the system but "noautoaccts" is
128	in FEATURES, portage will abort with a message instructing the user to
129	add the accounts that are listed in EUSERS and EGROUPS. This is
130	obviously a required step before the package will be emerged.
131
132
133	Rationale
134	=========
135
136	Developers no longer have to worry about how to properly add users/groups
137	to systems and worry about whether or not their code will work on all
138	systems (LDAP vs local shadow vs cross compile vs etc...). Users can
139	easily override the defaults Gentoo has before dictated. The default
140	passwd and group database can once again be trimmed down to the barest of
141	accounts.
142
143
144	Backwards Compatibility
145	=======================
146
147	Handled in similar fashion as other portage rollouts. When using the new
148	account system, add a DEPEND for the required version of portage to the
149	ebuild.
150
151
152	References
153	==========
154
155	.. [#APIBUG] http://bugs.gentoo.org/show_bug.cgi?id=8634
156
157
158	Copyright
159	=========
160
161	This document has been placed in the public domain.