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

1 g2boojum 1.1 GLEP: 27
2 g2boojum 1.2 Title: Portage Management of UIDs/GIDs
3 g2boojum 1.3 Version: $Revision: 1.2 $
4     Last-Modified: $Date: 2004/05/29 14:48:18 $
5 g2boojum 1.1 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 g2boojum 1.3 Post-History: 29-May-2004, 20-Jul-2004
11 g2boojum 1.1
12    
13 g2boojum 1.3 Status
14     ======
15    
16     This GLEP was approved as-is on 14-Jun-2004.
17    
18 g2boojum 1.1 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