/[gentoo]/xml/htdocs/proj/en/glep/glep-0027.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0027.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.4 - (show annotations) (download)
Thu Sep 15 02:39:54 2005 UTC (9 years, 1 month ago) by vapier
Branch: MAIN
Changes since 1.3: +20 -17 lines
File MIME type: text/plain
touchup to not require xml

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

  ViewVC Help
Powered by ViewVC 1.1.20