/[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.3 - (show annotations) (download)
Tue Jul 20 18:19:27 2004 UTC (10 years, 2 months ago) by g2boojum
Branch: MAIN
Changes since 1.2: +8 -3 lines
File MIME type: text/plain
Mark approved.

1 GLEP: 27
2 Title: Portage Management of UIDs/GIDs
3 Version: $Revision: 1.2 $
4 Last-Modified: $Date: 2004/05/29 14:48:18 $
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 A new directory will need to be added to the rsync tree to store the
56 files that define the default values for new accounts.
57
58 ::
59
60 portage/profiles/accounts/
61 user/<username>.xml
62 group/<groupname>.xml
63 accounts.xml
64
65 The files are named with the respective user/group name since they need
66 to be unique in their respective domains. For example, the file
67 detailing the ntp user would be located accounts/user/ntp.xml. Each
68 username.xml file will detail the required information about each user.
69 Certain account features that exist on one class of systems (Linux) but
70 not on others (\*BSD) can be tagged as such. Each groupname.xml will
71 follow similar guidelines. The accounts.xml will be used to describe
72 global account defaults such as the default range of 'valid system' ids.
73 For example, if the UID 123 is already used on a system, but the ntp
74 user defaults to '123', we obviously cannot just duplicate it. So we
75 would select the next available UID on the system based upon the range
76 defined here.
77
78
79 Local Overrides
80 '''''''''''''''
81
82 Following the tried and true style of custom local portage files being
83 found in /etc/portage, this new system will follow the same. Users can
84 setup their own directory heirarchy in /etc/portage/accounts/ that mimics
85 the heirarchy found in the portage tree. When portage attempts to add a
86 new user, it will first check /etc/portage/accounts/user/<username>.xml.
87 If it does not exist, it will simply use the default definition in the
88 portage tree.
89
90
91 Developer Interface
92 -------------------
93
94
95 EUSERS + EGROUPS
96 ''''''''''''''''
97
98 Ebuilds that wish to add users or groups to the system must set these
99 variables. They are both space delimited lists that tells portage what
100 users/groups must be added to the system before emerging the ebuild. The
101 maintainer of the ebuild can assume the users/groups they have listed
102 exist before the functions in the ebuild (pkg_setup, src_install, etc...)
103 are ever run.
104
105
106 Defining Accounts
107 '''''''''''''''''
108
109 Any developer is free to add users/groups in their ebuilds provided they
110 create the required account definition files.
111
112
113 User Interface
114 --------------
115
116
117 users-update
118 ''''''''''''
119
120 When this script is run, all the users/groups that have been added by
121 portage to the system will be shown along with the packages that have
122 added said users/groups. Here they can delete accounts that are no longer
123 required by the currently installed packages (and optionally run a
124 script that will try to locate all files on the system that may still be
125 owned by the account).
126
127
128 FEATURES=noautoaccts
129 ''''''''''''''''''''
130
131 This is for the people who never want portage creating accounts for them.
132 When portage needs to add an account to the system but "noautoaccts" is
133 in FEATURES, portage will abort with a message instructing the user to
134 add the accounts that are listed in EUSERS and EGROUPS. This is
135 obviously a required step before the package will be emerged.
136
137
138 Rationale
139 =========
140
141 Developers no longer have to worry about how to properly add users/groups
142 to systems and worry about whether or not their code will work on all
143 systems (LDAP vs local shadow vs cross compile vs etc...). Users can
144 easily override the defaults Gentoo has before dictated. The default
145 passwd and group database can once again be trimmed down to the barest of
146 accounts.
147
148
149 Backwards Compatibility
150 =======================
151
152 Handled in similar fashion as other portage rollouts. When using the new
153 account system, add a DEPEND for the required version of portage to the
154 ebuild.
155
156
157 References
158 ==========
159
160 .. [#APIBUG] http://bugs.gentoo.org/show_bug.cgi?id=8634
161
162
163 Copyright
164 =========
165
166 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20