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

1 g2boojum 1.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