/[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.1 - (show annotations) (download)
Sat May 29 14:31:58 2004 UTC (10 years, 7 months ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
new glep

1 GLEP: 27
2 Title: Portage User Management
3 Version: $Revision: 1.4 $
4 Last-Modified: $Date: 2003/07/19 12:09:20 $
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.

  ViewVC Help
Powered by ViewVC 1.1.20