1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
---
GLEP: 27
Title: Portage Management of UIDs/GIDs
Author: Mike Frysinger <vapier@gentoo.org>
Type: Standards Track
Status: Deferred
Version: 1
Created: 2004-05-29
Last-Modified: 2017-10-13
Post-History: 2004-05-29, 2004-07-20
Content-Type: text/x-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.
References
==========
.. [#APIBUG] http://bugs.gentoo.org/show_bug.cgi?id=8634
Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License. To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/3.0/.
|
GitWeb