|
rlm@1
|
1
|
|
rlm@1
|
2 AUTHOR: Matthias S. Benkmann <article at winterdrache dot de>
|
|
rlm@1
|
3
|
|
rlm@1
|
4 DATE: 2007-10-20
|
|
rlm@1
|
5
|
|
rlm@1
|
6 LICENSE: Creative Commons Attribution-Share Alike 3.0
|
|
rlm@1
|
7 (http://creativecommons.org/licenses/by-sa/3.0/)
|
|
rlm@1
|
8
|
|
rlm@1
|
9 SYNOPSIS: More Control and Package Management using Package Users (v1.4)
|
|
rlm@1
|
10
|
|
rlm@1
|
11 DESCRIPTION:
|
|
rlm@1
|
12 -You want to know which packages your files belong to ?
|
|
rlm@1
|
13 -You want to deinstall software that doesn't have make uninstall ?
|
|
rlm@1
|
14 -You are bothered by programs installed setuid root behind your back ?
|
|
rlm@1
|
15 -You don't like packages quietly overwriting files from other packages ?
|
|
rlm@1
|
16 -You don't like package managers like RPM ?
|
|
rlm@1
|
17 -YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?
|
|
rlm@1
|
18
|
|
rlm@1
|
19 ATTACHMENTS:
|
|
rlm@1
|
20 http://www.linuxfromscratch.org/hints/downloads/attachments/more_control_and_pkg_man/more_control_helpers.tar.bz2
|
|
rlm@1
|
21
|
|
rlm@1
|
22 PREREQUISITES:
|
|
rlm@1
|
23 For use with LFS book 6.2: Brain.
|
|
rlm@1
|
24 For use with LFS book later than 6.2: Brain (awake, good working condition).
|
|
rlm@1
|
25
|
|
rlm@1
|
26 HINT:
|
|
rlm@1
|
27
|
|
rlm@1
|
28 ###########################################################################
|
|
rlm@1
|
29 Contents
|
|
rlm@1
|
30 ###########################################################################
|
|
rlm@1
|
31
|
|
rlm@1
|
32 1. Preface
|
|
rlm@1
|
33 2. Overview
|
|
rlm@1
|
34
|
|
rlm@1
|
35 - PART 1: General Information -
|
|
rlm@1
|
36
|
|
rlm@1
|
37 3. Package Users
|
|
rlm@1
|
38 3.1 Introduction
|
|
rlm@1
|
39 3.2 User Name
|
|
rlm@1
|
40 3.3 Groups
|
|
rlm@1
|
41 3.4 Home Directory
|
|
rlm@1
|
42 4. Common Problems
|
|
rlm@1
|
43 4.1 Introduction
|
|
rlm@1
|
44 4.2 General Procedure
|
|
rlm@1
|
45 4.3 Permission Changes
|
|
rlm@1
|
46 4.4 Ownership Changes
|
|
rlm@1
|
47 4.5 Write to Non-Install Directory
|
|
rlm@1
|
48 4.6 Delete or Overwrite File
|
|
rlm@1
|
49 4.7 /sbin/ldconfig
|
|
rlm@1
|
50 4.8 What Commands to Run as a Package User
|
|
rlm@1
|
51 5. The more_control_helpers Archive
|
|
rlm@1
|
52 5.1 Overview
|
|
rlm@1
|
53 5.2 The Wrappers
|
|
rlm@1
|
54 5.3 add_package_user/install_package
|
|
rlm@1
|
55 5.4 forall_direntries_from
|
|
rlm@1
|
56 5.5 uninstall_package
|
|
rlm@1
|
57 5.6 list_suspicious_files/list_suspicious_files_from
|
|
rlm@1
|
58 5.7 list_package
|
|
rlm@1
|
59 5.8 grep_all_regular_files_for
|
|
rlm@1
|
60 5.9 The etc Directory
|
|
rlm@1
|
61 5.10 Temporary Files
|
|
rlm@1
|
62
|
|
rlm@1
|
63 - PART 2: LFS Specifics -
|
|
rlm@1
|
64
|
|
rlm@1
|
65 6. Pre-Chroot Phase (Chapter 5)
|
|
rlm@1
|
66 7. Chroot Phase (Chapter 6)
|
|
rlm@1
|
67 7.1 Preparations
|
|
rlm@1
|
68 7.2 Walkthrough: Installing linux-libc-headers
|
|
rlm@1
|
69 7.3 Known Issues with LFS Packages
|
|
rlm@1
|
70 8. Sanity Checks
|
|
rlm@1
|
71 8.1 Suspicious Files
|
|
rlm@1
|
72 8.2 References to Temporary Files
|
|
rlm@1
|
73
|
|
rlm@1
|
74 - APPENDICES -
|
|
rlm@1
|
75
|
|
rlm@1
|
76 A. Security Issues
|
|
rlm@1
|
77 A.1 NFS
|
|
rlm@1
|
78 A.2 Daemons
|
|
rlm@1
|
79 B. Package Categories
|
|
rlm@1
|
80 C. Acknowledgements and Changelog
|
|
rlm@1
|
81
|
|
rlm@1
|
82
|
|
rlm@1
|
83 ###########################################################################
|
|
rlm@1
|
84 1. Preface
|
|
rlm@1
|
85 ###########################################################################
|
|
rlm@1
|
86
|
|
rlm@1
|
87 Let's say I have written a program that you would like to use. To make it
|
|
rlm@1
|
88 easier for you I come over to install it for you. Would you give me the root
|
|
rlm@1
|
89 account and then leave the room ? No ? Then why do you give it to complete
|
|
rlm@1
|
90 strangers who you have never seen in your life, to install software packages
|
|
rlm@1
|
91 pulled from some Internet server, that come with no warranty and don't even
|
|
rlm@1
|
92 list their contents in the README, although they will happily spread them all
|
|
rlm@1
|
93 over your system ?
|
|
rlm@1
|
94
|
|
rlm@1
|
95 It is a mystery why Unix admins who wouldn't even trust their employer with
|
|
rlm@1
|
96 more than a normal user account carelessly execute complex and incomprehensible
|
|
rlm@1
|
97 installation scripts with full root rights.
|
|
rlm@1
|
98
|
|
rlm@1
|
99 Users and groups are the basic security principle in a Unix system. They have
|
|
rlm@1
|
100 been used successfully for a long time to monitor who has created a file and
|
|
rlm@1
|
101 to control who is allowed to delete or change it. But this control has only
|
|
rlm@1
|
102 been imposed on the files of ordinary users. What a waste! I suggest to extend
|
|
rlm@1
|
103 this control to all system files.
|
|
rlm@1
|
104
|
|
rlm@1
|
105 The general idea is to create package users, i.e. user accounts with restricted
|
|
rlm@1
|
106 rights, to build and install software packages, rather than doing these tasks
|
|
rlm@1
|
107 as root. Not only does this give you more control over what build and install
|
|
rlm@1
|
108 scripts may or may not do, it can also serve as a quite useful package
|
|
rlm@1
|
109 management system.
|
|
rlm@1
|
110
|
|
rlm@1
|
111
|
|
rlm@1
|
112 #############################################################################
|
|
rlm@1
|
113 2. Overview
|
|
rlm@1
|
114 #############################################################################
|
|
rlm@1
|
115
|
|
rlm@1
|
116 This hint is divided into 3 parts. The first part contains general information
|
|
rlm@1
|
117 about the package user method. This part is the most important part of the
|
|
rlm@1
|
118 hint. Read it thoroughly. The second part explains how to apply the package
|
|
rlm@1
|
119 user method to the building of an LFS system.
|
|
rlm@1
|
120 Finally, part 3 of this hint is the Appendix with information that would not
|
|
rlm@1
|
121 fit anywhere else or that is not of general interest.
|
|
rlm@1
|
122
|
|
rlm@1
|
123 It is inevitable that part 2 will become outdated with time as the LFS book
|
|
rlm@1
|
124 changes and new versions of the software packages used with LFS are released.
|
|
rlm@1
|
125 I make no attempt to track these changes.
|
|
rlm@1
|
126 When someone reports an issue with a package I will incorporate
|
|
rlm@1
|
127 it into the hint, but larger changes that might be required due to changes in
|
|
rlm@1
|
128 the LFS build methodology could take a long time to get included. The reason
|
|
rlm@1
|
129 for this (aside from lack of time) is that I consider part 2 as bonus material
|
|
rlm@1
|
130 that helps people get started but is not essential. Part 1 describes the
|
|
rlm@1
|
131 concepts, which are independent of package versions or the LFS book, and you
|
|
rlm@1
|
132 will have to rely on this information whenever part 2 fails. Don't forget
|
|
rlm@1
|
133 that part 2 only deals with the packages used by the LFS book. For all the
|
|
rlm@1
|
134 other packages you install on your system after that even an up-to-date
|
|
rlm@1
|
135 part 2 would offer no aid anyway.
|
|
rlm@1
|
136
|
|
rlm@1
|
137 The previous paragraph might sound discouraging, and as you read more from the
|
|
rlm@1
|
138 hint it is possible that you get the impression that the package user
|
|
rlm@1
|
139 method is complicated, causes lots of difficult problems and is overall too
|
|
rlm@1
|
140 much trouble for anyone but a real hardcore admin with programming experience.
|
|
rlm@1
|
141 But you would be mistaken.
|
|
rlm@1
|
142 First of all, many things experienced as installation problems when working
|
|
rlm@1
|
143 with the package user system are in fact desirable features.
|
|
rlm@1
|
144 If `make install' fails for some package, because it attempts to install a
|
|
rlm@1
|
145 file with the same name as a pre-existing file from another package, you
|
|
rlm@1
|
146 should not curse the fact that you have to spend additional time to resolve
|
|
rlm@1
|
147 this issue. Instead you should be happy that you have been alerted of this
|
|
rlm@1
|
148 collision that, had it gone unnoticed, could have messed up your system in
|
|
rlm@1
|
149 more or less subtle ways.
|
|
rlm@1
|
150 Secondly, the package user system is not an all-or-nothing approach. It
|
|
rlm@1
|
151 works on a per-package basis. If a package gives you too much trouble, you
|
|
rlm@1
|
152 can always decide to chicken out and finish the installation as root.
|
|
rlm@1
|
153 Finally, the more_control_helpers archive provided with this hint contains
|
|
rlm@1
|
154 several useful scripts that automate many aspects of software installation
|
|
rlm@1
|
155 as a package user and, together with the tips given in this hint, add a lot
|
|
rlm@1
|
156 of value to the package user system.
|
|
rlm@1
|
157 So do not pass judgement until you have read at least the complete part 1,
|
|
rlm@1
|
158 including the description of the more_control_helpers.
|
|
rlm@1
|
159
|
|
rlm@1
|
160
|
|
rlm@1
|
161 ---------------------- PART 1: General Information --------------------------
|
|
rlm@1
|
162
|
|
rlm@1
|
163
|
|
rlm@1
|
164 #############################################################################
|
|
rlm@1
|
165 3. Package Users
|
|
rlm@1
|
166 #############################################################################
|
|
rlm@1
|
167
|
|
rlm@1
|
168 3.1 Introduction
|
|
rlm@1
|
169 ----------------
|
|
rlm@1
|
170
|
|
rlm@1
|
171 The basic idea of this scheme is easily explained. Every package belongs to a
|
|
rlm@1
|
172 certain "package user". When you install a package, you build and install
|
|
rlm@1
|
173 the package as this package user, causing all files that are installed to be
|
|
rlm@1
|
174 owned by the package user. As a consequence all the usual package management
|
|
rlm@1
|
175 tasks can be comfortably achieved through the use of standard command line
|
|
rlm@1
|
176 utilities. A simple `ls -l <file>' will tell you, for instance, what package
|
|
rlm@1
|
177 <file> belongs to and a `find -user ...' command allows you to perform an
|
|
rlm@1
|
178 operation on all the files belonging to a certain package, e.g. delete them
|
|
rlm@1
|
179 to uninstall the package.
|
|
rlm@1
|
180
|
|
rlm@1
|
181 But package management is not all that package users are good for. Because
|
|
rlm@1
|
182 package users do not have root-rights, the installation of a package is
|
|
rlm@1
|
183 limited in what it can do. One thing that a package user is not allowed to do,
|
|
rlm@1
|
184 for example, is to overwrite files from a different package user. Clashes
|
|
rlm@1
|
185 between different packages that want to install a binary, library or header
|
|
rlm@1
|
186 file of the same name are more common than you might think. With package users
|
|
rlm@1
|
187 you never run the risk of package B's installation destroying files from
|
|
rlm@1
|
188 package A silently without you noticing. Every attempt of doing this during
|
|
rlm@1
|
189 package B's installation will cause a "Permission denied" or
|
|
rlm@1
|
190 "Operation not permitted" error so that you have the chance of taking
|
|
rlm@1
|
191 appropriate steps.
|
|
rlm@1
|
192 Another thing that package users are not allowed to do is install setuid root
|
|
rlm@1
|
193 binaries. The decision to make a binary setuid root is also something that a
|
|
rlm@1
|
194 prudent admin does not want to leave up to the creator of a software package.
|
|
rlm@1
|
195
|
|
rlm@1
|
196 Usually package user accounts have no valid password so that only root can su
|
|
rlm@1
|
197 to a package user, which ensures that package users do not open an additional
|
|
rlm@1
|
198 way into the system and undermine security. But you *may* set passwords
|
|
rlm@1
|
199 anyway to allow a co-admin who you want to be able to install and maintain
|
|
rlm@1
|
200 certain software packages to do so without having access to the actual root
|
|
rlm@1
|
201 account. This co-admin could for instance install, delete, change additional
|
|
rlm@1
|
202 libraries which might be necessary for his workgroup. He would be unable,
|
|
rlm@1
|
203 though, to remove or modify libraries which don't belong to him/her, such as
|
|
rlm@1
|
204 libc.
|
|
rlm@1
|
205
|
|
rlm@1
|
206
|
|
rlm@1
|
207 3.2 User Name
|
|
rlm@1
|
208 -------------
|
|
rlm@1
|
209
|
|
rlm@1
|
210 You don't need to drive yourself nuts trying to come up with 8 character
|
|
rlm@1
|
211 names for the package users. I always use the name of the package without
|
|
rlm@1
|
212 the version number, including dashes and possibly exceeding 8 characters in
|
|
rlm@1
|
213 length, e.g. "util-linux", and in the several years that I've been using this
|
|
rlm@1
|
214 scheme I have not encountered any problems, nor has anyone else reported
|
|
rlm@1
|
215 trouble. The 8-character limit on user names seems to be a thing of the past.
|
|
rlm@1
|
216
|
|
rlm@1
|
217 TIP:
|
|
rlm@1
|
218 You can use bash's programmable completion feature to save yourself some
|
|
rlm@1
|
219 typing when entering commands that take a user name as an argument, such as
|
|
rlm@1
|
220 su, finger or pinky. The command
|
|
rlm@1
|
221
|
|
rlm@1
|
222 complete -o default -o nospace -A user su finger pinky
|
|
rlm@1
|
223
|
|
rlm@1
|
224 tells bash to tab-complete words as user names for the commands su,
|
|
rlm@1
|
225 finger and pinky.
|
|
rlm@1
|
226 With this in place you can simply type `su linux-li<TAB>' and bash
|
|
rlm@1
|
227 will complete this to `su linux-libc-headers' (assuming that you have a
|
|
rlm@1
|
228 package user named "linux-libc-headers").
|
|
rlm@1
|
229 "-o default" tells bash that if a suitable user name does not exist, the
|
|
rlm@1
|
230 default completion shall be attempted.
|
|
rlm@1
|
231 "-o nospace" prevents the addition of a space after the completed word.
|
|
rlm@1
|
232
|
|
rlm@1
|
233 This is a very useful command to put into root's .bashrc and .bash_profile.
|
|
rlm@1
|
234
|
|
rlm@1
|
235 BTW, at http://freshmeat.net/projects/bashcompletion/
|
|
rlm@1
|
236 you can find a project that offers sophisticated completions for many
|
|
rlm@1
|
237 other commands.
|
|
rlm@1
|
238
|
|
rlm@1
|
239 Or switch to zsh (http://freshmeat.net/projects/zsh/). It's more powerful
|
|
rlm@1
|
240 and less buggy than bash.
|
|
rlm@1
|
241
|
|
rlm@1
|
242
|
|
rlm@1
|
243 3.3 Groups
|
|
rlm@1
|
244 ----------
|
|
rlm@1
|
245
|
|
rlm@1
|
246 Every package user belongs to at least 2 groups. One of these groups is
|
|
rlm@1
|
247 the "install" group, which all package users (and only package users) belong
|
|
rlm@1
|
248 to. All directories that packages are allowed to install stuff in belong to
|
|
rlm@1
|
249 the install group. This includes directories such as /bin and /usr/bin but
|
|
rlm@1
|
250 excludes directories like /root or /.
|
|
rlm@1
|
251 The directories owned by the install group are always group-writable.
|
|
rlm@1
|
252 This would be enough for the package management aspects, but without further
|
|
rlm@1
|
253 preparation this would not give added security or control because every
|
|
rlm@1
|
254 package could replace the files from a different package (the change would
|
|
rlm@1
|
255 be visible in the output from `ls -l', though).
|
|
rlm@1
|
256 For this reason all install directories get the sticky attribute. This
|
|
rlm@1
|
257 allows users to create new files and delete or modify their own files in
|
|
rlm@1
|
258 the directory, but files from other users can not be modified or removed.
|
|
rlm@1
|
259 In the rest of this hint, whenever the term "install directory" is used, it
|
|
rlm@1
|
260 refers to a directory that belongs to group install, is group-writable and
|
|
rlm@1
|
261 sticky. IOW, to turn <dir> into an install directory you would do
|
|
rlm@1
|
262
|
|
rlm@1
|
263 chgrp install <dir> && chmod g+w,o+t <dir>
|
|
rlm@1
|
264
|
|
rlm@1
|
265 Although the install group is crucial for the package user system, it is
|
|
rlm@1
|
266 implemented as a supplementary group, rather than as the primary group for
|
|
rlm@1
|
267 package users. This has at least 2 advantages.
|
|
rlm@1
|
268 One advantage is that this makes it easy to get a list of all packages
|
|
rlm@1
|
269 installed on the system with the command
|
|
rlm@1
|
270
|
|
rlm@1
|
271 grep install /etc/group
|
|
rlm@1
|
272
|
|
rlm@1
|
273 A more important point, however, is that the primary group is the
|
|
rlm@1
|
274 one that files created by the package user will belong to. So it will be
|
|
rlm@1
|
275 printed in the output of `ls -l' and is subject to find's "-group" test.
|
|
rlm@1
|
276 This makes it very useful for organizational purposes.
|
|
rlm@1
|
277 Following are some suggestions for how to use the primary group.
|
|
rlm@1
|
278
|
|
rlm@1
|
279 1. group name = user name
|
|
rlm@1
|
280
|
|
rlm@1
|
281 Under this scheme the package user for the bash package would be
|
|
rlm@1
|
282 bash:bash. `ls -l /bin/bash' would show something like this
|
|
rlm@1
|
283
|
|
rlm@1
|
284 -rwxr-xr-x 1 bash bash 1731859 Feb 30 2005 /bin/bash
|
|
rlm@1
|
285
|
|
rlm@1
|
286 An important advantage of this scheme is that the user information is
|
|
rlm@1
|
287 not lost when you make a file setuid root, which requires changing
|
|
rlm@1
|
288 the file's owner. Because of this advantage, this scheme is the one
|
|
rlm@1
|
289 recommended by this hint. However, the hint's instructions will work
|
|
rlm@1
|
290 fine if you choose a different scheme.
|
|
rlm@1
|
291
|
|
rlm@1
|
292 2. group name = package category
|
|
rlm@1
|
293
|
|
rlm@1
|
294 Under this scheme, you would have certain package categories, such as
|
|
rlm@1
|
295 games, system, net,... and bash, being a system program, would possibly
|
|
rlm@1
|
296 belong to the system group, so that `ls -l /bin/bash' would show something
|
|
rlm@1
|
297 like this
|
|
rlm@1
|
298
|
|
rlm@1
|
299 -rwxr-xr-x 1 bash system 1731859 Jul 4 1776 /bin/bash
|
|
rlm@1
|
300
|
|
rlm@1
|
301 This system is nice, but probably not as useful as #1 above, unless you
|
|
rlm@1
|
302 have a real use for this categorization.
|
|
rlm@1
|
303 For a possible categorization see Appendix B at the end of this hint.
|
|
rlm@1
|
304
|
|
rlm@1
|
305 3. group name = identifier for a real group of people
|
|
rlm@1
|
306
|
|
rlm@1
|
307 Under this scheme, the group would correspond to a real group of people in
|
|
rlm@1
|
308 meatspace, e.g. the group of admins responsible for the package.
|
|
rlm@1
|
309 If you need something like this you'll know best what it looks like and how
|
|
rlm@1
|
310 to implement it, so no further discussion of this method will be given here.
|
|
rlm@1
|
311
|
|
rlm@1
|
312
|
|
rlm@1
|
313 3.4 Home Directory
|
|
rlm@1
|
314 ------------------
|
|
rlm@1
|
315
|
|
rlm@1
|
316 Although it is well possible not to have a valid home directory for package
|
|
rlm@1
|
317 users or to have just one home directory shared by all package users, that
|
|
rlm@1
|
318 would be a wasted opportunity. Having individual home directories for the
|
|
rlm@1
|
319 package users offers a nice way to organize tarballs, patches, build scripts,
|
|
rlm@1
|
320 notes and all the other per-package information that you accumulate with time.
|
|
rlm@1
|
321
|
|
rlm@1
|
322 I suggest to use the home directory /usr/src/<package> for a package user
|
|
rlm@1
|
323 called <package> with the contents detailed below. The more_control_helpers
|
|
rlm@1
|
324 archive contains scripts and skeleton files that implement this suggestion.
|
|
rlm@1
|
325
|
|
rlm@1
|
326 .bash_profile:
|
|
rlm@1
|
327 You will usually want to have the same environment for all package
|
|
rlm@1
|
328 users, so it is a good idea to make .bash_profile a symbolic link
|
|
rlm@1
|
329 to a file in a central location. The more_control_helpers example
|
|
rlm@1
|
330 uses /etc/pkgusr/bash_profile for this purpose.
|
|
rlm@1
|
331
|
|
rlm@1
|
332 .bashrc:
|
|
rlm@1
|
333 As for .bash_profile a symlink is a good idea for .bashrc. The
|
|
rlm@1
|
334 more_control_helpers example uses /etc/pkgusr/bashrc as link target.
|
|
rlm@1
|
335 Under normal circumstances package users are not
|
|
rlm@1
|
336 (and even can not be) used for logging into the system, so there
|
|
rlm@1
|
337 is little reason to distinguish between login and non-login shells
|
|
rlm@1
|
338 for package users. Therefore, the example bashrc from
|
|
rlm@1
|
339 more_control_helpers simply sources .bash_profile.
|
|
rlm@1
|
340 This makes sure that the same environment will be used, regardless
|
|
rlm@1
|
341 of whether `su <package>' or `su - <package>' is used to become
|
|
rlm@1
|
342 the package user.
|
|
rlm@1
|
343
|
|
rlm@1
|
344 .project:
|
|
rlm@1
|
345 The contents of this file are printed by the commands
|
|
rlm@1
|
346 `finger -l <user>' and 'pinky -l <user>' so .project is a
|
|
rlm@1
|
347 good place for putting information about a package. You should
|
|
rlm@1
|
348 keep the contents of the .project files for your package users
|
|
rlm@1
|
349 up-to-date.
|
|
rlm@1
|
350
|
|
rlm@1
|
351 source code:
|
|
rlm@1
|
352 The package user's home directory is the perfect place for storing
|
|
rlm@1
|
353 a package's source code. This includes tarballs for different
|
|
rlm@1
|
354 versions, CVS checkouts, unpacked source trees for building,...
|
|
rlm@1
|
355
|
|
rlm@1
|
356 build script(s):
|
|
rlm@1
|
357 Package user installations require more careful examination of build
|
|
rlm@1
|
358 and install messages than installations done as root, because of
|
|
rlm@1
|
359 the package user-specific problems that can occur. Therefore it is
|
|
rlm@1
|
360 unwise to simply copy'n'paste installation instructions from the
|
|
rlm@1
|
361 LFS book. Build scripts allow you to use sophisticated output
|
|
rlm@1
|
362 redirection for logging purposes that is impractical for direct
|
|
rlm@1
|
363 entry on the command line. The build script skeleton included in
|
|
rlm@1
|
364 the more_control_helpers archive demonstrates this.
|
|
rlm@1
|
365
|
|
rlm@1
|
366
|
|
rlm@1
|
367 ############################################################################
|
|
rlm@1
|
368 4. Common Problems
|
|
rlm@1
|
369 ############################################################################
|
|
rlm@1
|
370
|
|
rlm@1
|
371 4.1 Introduction
|
|
rlm@1
|
372 ----------------
|
|
rlm@1
|
373
|
|
rlm@1
|
374 Software installation is the crux of the package user system. Because
|
|
rlm@1
|
375 installation scripts are often written under the assumption that they will be
|
|
rlm@1
|
376 executed as root, they sometimes fail when executed by a package user.
|
|
rlm@1
|
377 Once this hurdle is passed and a package has been installed, there's usually no
|
|
rlm@1
|
378 difference to a root-installation. A few programs insist that certain
|
|
rlm@1
|
379 security-sensitive files be owned by root and will not execute otherwise,
|
|
rlm@1
|
380 but this is the rare exception.
|
|
rlm@1
|
381 This chapter presents some more or less common problems that you will
|
|
rlm@1
|
382 encounter when using package user accounts to install software, together with
|
|
rlm@1
|
383 guidelines on how to deal with these issues.
|
|
rlm@1
|
384 Although I've said it before I will say it again: Many of the problems you
|
|
rlm@1
|
385 encounter during a package user installation are desirable features of the
|
|
rlm@1
|
386 package user system. You want installation to fail rather than have
|
|
rlm@1
|
387 potentially dangerous actions performed behind your back with root rights.
|
|
rlm@1
|
388
|
|
rlm@1
|
389
|
|
rlm@1
|
390 4.2 General Procedure
|
|
rlm@1
|
391 ---------------------
|
|
rlm@1
|
392
|
|
rlm@1
|
393 When an installation fails it is almost always due to a "Permission denied"
|
|
rlm@1
|
394 or "Operation not permitted" error while executing a command during
|
|
rlm@1
|
395 `make install'. The first thing you have to do is identify the command that
|
|
rlm@1
|
396 is causing the problem. Usually you will find this in the make output right
|
|
rlm@1
|
397 before the error message. Once you have identified the culprit, you have to
|
|
rlm@1
|
398 decide whether the action that is attempted is illegitimate, partially
|
|
rlm@1
|
399 legitimate or completely legitimate. Illegitimate commands can simply be
|
|
rlm@1
|
400 removed from the Makefile. The other 2 possibilities are more difficult to
|
|
rlm@1
|
401 deal with. You either have to change the condition that makes the command fail
|
|
rlm@1
|
402 or you have to change or sometimes remove the command and make a note if your
|
|
rlm@1
|
403 change suppresses a legitimate action.
|
|
rlm@1
|
404
|
|
rlm@1
|
405 After you've made changes to solve a certain problem, you reattempt the
|
|
rlm@1
|
406 installation and solve any remaining problems until the installation
|
|
rlm@1
|
407 succeeds. Once you've reached that point it is time to perform any remaining
|
|
rlm@1
|
408 legitimate actions that you've had to disable, such as make certain binaries
|
|
rlm@1
|
409 setuid root.
|
|
rlm@1
|
410
|
|
rlm@1
|
411 Note that often Makefiles are generated during the configure step, sometimes
|
|
rlm@1
|
412 even later in the build process. If you want to apply changes before the
|
|
rlm@1
|
413 configure step you will usually have to edit files called "Makefile.in".
|
|
rlm@1
|
414
|
|
rlm@1
|
415
|
|
rlm@1
|
416 4.3 Permission Changes
|
|
rlm@1
|
417 ----------------------
|
|
rlm@1
|
418
|
|
rlm@1
|
419 Some unsophisticated build systems that don't use the mkinstalldirs script to
|
|
rlm@1
|
420 create installation target directories are very poorly written. Instead of
|
|
rlm@1
|
421 testing whether a target directory exists, they simply attempt to create
|
|
rlm@1
|
422 it with default permissions. This problem usually manifests as a line such
|
|
rlm@1
|
423 as "install -d $(prefix)/bin" in the Makefile. In the common case where
|
|
rlm@1
|
424 prefix=/usr this would attempt to create the /usr/bin directory. If the target
|
|
rlm@1
|
425 directory already exists, as in this case, install will attempt to change its
|
|
rlm@1
|
426 permissions to the default permissions (or those passed on the command line).
|
|
rlm@1
|
427 Of course a package user is not allowed to change the permissions of
|
|
rlm@1
|
428 /usr/bin and so the command fails with a message like
|
|
rlm@1
|
429 "install: cannot change permissions of `/usr/bin': Operation not permitted"
|
|
rlm@1
|
430 This is an example of a completely illegitimate command. Just remove it from
|
|
rlm@1
|
431 the Makefile and everything's fine.
|
|
rlm@1
|
432
|
|
rlm@1
|
433
|
|
rlm@1
|
434 4.4 Ownership Changes
|
|
rlm@1
|
435 ---------------------
|
|
rlm@1
|
436
|
|
rlm@1
|
437 The most common situation when a package wants to change the ownership of
|
|
rlm@1
|
438 files during installation is when it wants to install setuid root binaries.
|
|
rlm@1
|
439 A common command to do this would be something like
|
|
rlm@1
|
440 "install -c -m 4755 -o root name /usr/bin/name" and the error message would
|
|
rlm@1
|
441 look like this:
|
|
rlm@1
|
442 "install: cannot change ownership of `name': Operation not permitted"
|
|
rlm@1
|
443 The change of ownership is hidden in the "-o root" switch to install, which
|
|
rlm@1
|
444 tells it to make the target file owned by root.
|
|
rlm@1
|
445 The command is at least partially legitimate, because you probably want the
|
|
rlm@1
|
446 binary to be installed. Whether you actually want it to be setuid root is
|
|
rlm@1
|
447 a different matter. The fact that a binary is commonly installed as setuid
|
|
rlm@1
|
448 root doesn't mean that you should make it so. You'll have to ask yourself if
|
|
rlm@1
|
449 normal users absolutely need to execute that binary. If you think they can
|
|
rlm@1
|
450 live without it you're better off not making it setuid root, because every
|
|
rlm@1
|
451 setuid root binary is a potential security hole. In any case you will
|
|
rlm@1
|
452 have to edit the Makefile and remove the offending switch, "-o root" in this
|
|
rlm@1
|
453 case, so that the installation can succeed. Note that this will cause the
|
|
rlm@1
|
454 binary to be installed setuid <package>, which of course makes no sense at all.
|
|
rlm@1
|
455 If you don't intend to make the binary setuid root after the installation, it
|
|
rlm@1
|
456 is best to change the "-m 4755" to "-m 755", so that it won't be installed
|
|
rlm@1
|
457 setuid at all.
|
|
rlm@1
|
458
|
|
rlm@1
|
459 TIP:
|
|
rlm@1
|
460 When you make a binary setuid root after the installation, use
|
|
rlm@1
|
461 `chown root /usr/bin/name' and not `chown root:root /usr/bin/name'.
|
|
rlm@1
|
462 This way you can keep original group of the file (i.e. the group of the
|
|
rlm@1
|
463 package user) intact. With the user name = group name scheme recommended for
|
|
rlm@1
|
464 package users this makes sure that you can identify the source package of
|
|
rlm@1
|
465 the binary even after making it setuid root.
|
|
rlm@1
|
466 Note that as a security measure chown resets the setuid bit,
|
|
rlm@1
|
467 so you will have to do `chmod u+s /usr/bin/name' after the chown.
|
|
rlm@1
|
468
|
|
rlm@1
|
469
|
|
rlm@1
|
470 4.5 Write to Non-Install Directory
|
|
rlm@1
|
471 ----------------------------------
|
|
rlm@1
|
472
|
|
rlm@1
|
473 Sometimes packages want to create files or directories in non-install
|
|
rlm@1
|
474 directories. 3 situations have to be distinguished in this case. The 1st
|
|
rlm@1
|
475 possibility is that the target directory should be an install directory.
|
|
rlm@1
|
476 An example of this is /usr/share/aclocal. This directory is not among the
|
|
rlm@1
|
477 standard system directories created when building an LFS system. It will be
|
|
rlm@1
|
478 created by the first package that has files to install there and will be
|
|
rlm@1
|
479 owned by the corresponding package user. The next package that wants to write
|
|
rlm@1
|
480 in it will fail to install. The remedy is simple. Just make the directory an
|
|
rlm@1
|
481 install directory. You don't even need to be root to do it. The package user
|
|
rlm@1
|
482 that owns the directory has the rights to make that change.
|
|
rlm@1
|
483
|
|
rlm@1
|
484 The 2nd possible reason for a package wanting to write to a non-install
|
|
rlm@1
|
485 directory is that the failing command is only partially legitimate, i.e. you
|
|
rlm@1
|
486 do want to have installed whatever it is meant to install, but you want it in
|
|
rlm@1
|
487 a different location. For example some packages install binaries that are not
|
|
rlm@1
|
488 meant to be called directly. The default location for these binaries is
|
|
rlm@1
|
489 sometimes called libexec and with prefix=/usr the package will attempt to
|
|
rlm@1
|
490 create /usr/libexec. In cases such as this you often don't have to change
|
|
rlm@1
|
491 any Makefiles. There is either a configure switch to change the directory in
|
|
rlm@1
|
492 question or it is just a matter of overriding a Makefile variable as in
|
|
rlm@1
|
493 `make libexecdir=/usr/lib install'.
|
|
rlm@1
|
494
|
|
rlm@1
|
495 The 3rd possible reason for an attempt to write to a non-install directory is
|
|
rlm@1
|
496 that the command in question is illegitimate, i.e. you don't want to have
|
|
rlm@1
|
497 installed whatever the package wants to install. As usual with illegitimate
|
|
rlm@1
|
498 commands you can edit the Makefile and just remove them. In the case of
|
|
rlm@1
|
499 a whole directory whose installation you want to suppress it could be too
|
|
rlm@1
|
500 much effort to remove all of the offending commands that want to install
|
|
rlm@1
|
501 files there. In this case an approach similar to that from the previous
|
|
rlm@1
|
502 paragraph can be more effective. Either through configure switches or
|
|
rlm@1
|
503 overriding of variables you change the directory in question to something
|
|
rlm@1
|
504 like <builddir>/foobar, where <builddir> is the directory in which build
|
|
rlm@1
|
505 commands are run (i.e. usually the top of the unpackaged source
|
|
rlm@1
|
506 tree). This will cause the package to create the unwanted directory inside
|
|
rlm@1
|
507 the build tree, which doesn't cause any permission problems and has the nice
|
|
rlm@1
|
508 side effect that it'll be deleted together with the build directory when you
|
|
rlm@1
|
509 clean up after the build.
|
|
rlm@1
|
510
|
|
rlm@1
|
511
|
|
rlm@1
|
512 4.6 Delete or Overwrite File
|
|
rlm@1
|
513 ----------------------------
|
|
rlm@1
|
514
|
|
rlm@1
|
515 In a perfect world one package should not mess with another package's files,
|
|
rlm@1
|
516 but in the real world conflicts do happen occasionally. While a normal
|
|
rlm@1
|
517 sysadmin installing as root won't notice this until it's too late, an admin
|
|
rlm@1
|
518 employing the package user system will have to deal with conflicts right away.
|
|
rlm@1
|
519 When a package tries to overwrite or delete a file or directory that is owned
|
|
rlm@1
|
520 by another package the attempt will fail. It will fail even inside install
|
|
rlm@1
|
521 directories because of the sticky bit.
|
|
rlm@1
|
522 Although sometimes difficult to implement, the solution to such a conflict is
|
|
rlm@1
|
523 easy to describe. You need to either remove (or rename) the old file or
|
|
rlm@1
|
524 directory before installing, or suppress the installation of the new file or
|
|
rlm@1
|
525 directory. The installation of individual binaries is sometimes easy to
|
|
rlm@1
|
526 prevent. If you find a line such as "PROGRAMS=foo bar fubar barfu" in the
|
|
rlm@1
|
527 Makefile and "foo" is the name of the conflicting binary, just try removing
|
|
rlm@1
|
528 it from that list. That may be sufficient to prevent it from being installed.
|
|
rlm@1
|
529
|
|
rlm@1
|
530
|
|
rlm@1
|
531 4.7 /sbin/ldconfig
|
|
rlm@1
|
532 ------------------
|
|
rlm@1
|
533
|
|
rlm@1
|
534 Packages that install libraries sometimes run /sbin/ldconfig as part of their
|
|
rlm@1
|
535 installation so that the dynamic libraries are properly registered on the
|
|
rlm@1
|
536 system. Because a package user is not allowed to overwrite /etc/ld.so.cache
|
|
rlm@1
|
537 ldconfig fails. This failure is commonly ignored in Makefiles, but you should
|
|
rlm@1
|
538 take note of it anyway, because you need to run ldconfig as root after
|
|
rlm@1
|
539 the installation. Alternatively, the more_control_helpers contain a wrapper
|
|
rlm@1
|
540 program that calls /sbin/ldconfig and can be made setuid root.
|
|
rlm@1
|
541
|
|
rlm@1
|
542
|
|
rlm@1
|
543 4.8 What Commands to Run as a Package User
|
|
rlm@1
|
544 ------------------------------------------
|
|
rlm@1
|
545
|
|
rlm@1
|
546 A common problem that new users of this hint have is to decide which commands
|
|
rlm@1
|
547 to run as a package user and which commands to run as root. The general rule
|
|
rlm@1
|
548 is that the only commands to run as a package user are those for building,
|
|
rlm@1
|
549 installing, removing and modifying the files that belong to *that* package
|
|
rlm@1
|
550 user's package. Everything else should be run as root as usual.
|
|
rlm@1
|
551 Some things you CAN/SHOULD NOT DO as a package user include
|
|
rlm@1
|
552
|
|
rlm@1
|
553 - starting daemons
|
|
rlm@1
|
554 - running udevstart
|
|
rlm@1
|
555 - stripping /lib/*
|
|
rlm@1
|
556
|
|
rlm@1
|
557
|
|
rlm@1
|
558 ############################################################################
|
|
rlm@1
|
559 5. The more_control_helpers Archive
|
|
rlm@1
|
560 ############################################################################
|
|
rlm@1
|
561
|
|
rlm@1
|
562 5.1 Overview
|
|
rlm@1
|
563 ------------
|
|
rlm@1
|
564
|
|
rlm@1
|
565 The more_control_helpers archive contains files to help you with building and
|
|
rlm@1
|
566 maintaining a system that uses the package user method. One thing that the
|
|
rlm@1
|
567 more_control_helpers archive contains are some LFS-specific temporary files
|
|
rlm@1
|
568 that are only needed for the building of your LFS system and will not remain
|
|
rlm@1
|
569 installed in a permanent location. Then there are the previously mentioned
|
|
rlm@1
|
570 example files that demonstrate the suggested use of the package user home
|
|
rlm@1
|
571 directories discussed earlier. Another group of files contained in the archive
|
|
rlm@1
|
572 is a set of scripts that help with package management aspects, such as
|
|
rlm@1
|
573 creating new package users and checking which files a particular package has
|
|
rlm@1
|
574 installed. Finally the more_control_helpers archive contains wrapper scripts
|
|
rlm@1
|
575 for some commands that handle many of the common problems discussed in the
|
|
rlm@1
|
576 previous chapter and make package user installations a lot easier.
|
|
rlm@1
|
577
|
|
rlm@1
|
578
|
|
rlm@1
|
579 5.2 The Wrappers
|
|
rlm@1
|
580 ----------------
|
|
rlm@1
|
581
|
|
rlm@1
|
582 The previous chapter discussed some common problems encountered during
|
|
rlm@1
|
583 package user builds and how to solve them. The solution to an installation
|
|
rlm@1
|
584 failure usually requires editing of one or more Makefiles. Making such changes
|
|
rlm@1
|
585 manually is annoying, even if it happens only occasionally, and whenever you
|
|
rlm@1
|
586 reinstall a package you have to make the changes again. Sed scripts and patches
|
|
rlm@1
|
587 can help with the latter problem, but they still have to be custom fitted to
|
|
rlm@1
|
588 every package that needs them. There is a better solution, though. While there
|
|
rlm@1
|
589 exist countless ways to install files, only very few are commonly used by
|
|
rlm@1
|
590 packages. The 5 commands mkdir, chgrp, chown, chmod and install are responsible
|
|
rlm@1
|
591 for most of the problems that arise during an LFS installation. This
|
|
rlm@1
|
592 prompted me to write wrapper scripts for these 5 commands that recognize
|
|
rlm@1
|
593 certain problematic patterns and deal with them automatically.
|
|
rlm@1
|
594
|
|
rlm@1
|
595 The instructions given in this hint in the LFS-specific part will instruct you
|
|
rlm@1
|
596 to install these wrappers in /usr/lib/pkgusr. If you do that and make sure
|
|
rlm@1
|
597 that this directory is the first entry in the PATH of every package user, then
|
|
rlm@1
|
598 they will save you a lot of time and effort in dealing with recurring issues.
|
|
rlm@1
|
599 Note that if you want to choose a directory other than /usr/lib/pkgusr for
|
|
rlm@1
|
600 the wrappers, you need to be careful. Some configure scripts ignore certain
|
|
rlm@1
|
601 locations. A subdirectory of /etc would not work, for instance, because /etc
|
|
rlm@1
|
602 is one of these locations.
|
|
rlm@1
|
603
|
|
rlm@1
|
604 It is important that you understand the limitations of the wrapper scripts.
|
|
rlm@1
|
605 They can fix some problems without user intervention, such as turning
|
|
rlm@1
|
606 newly created directories in /usr/share/locale into install directories.
|
|
rlm@1
|
607 But other problems by their very nature require manual intervention. When a
|
|
rlm@1
|
608 program tries to install a setuid root binary, for instance, the wrapper
|
|
rlm@1
|
609 scripts will suppress the attempt to change ownership of an installed file to
|
|
rlm@1
|
610 root. While that allows `make install' to complete without error, it is only
|
|
rlm@1
|
611 a partial solution. The wrapper scripts can not (and should not) take away
|
|
rlm@1
|
612 your responsibility for deciding whether the program in question should be
|
|
rlm@1
|
613 setuid root and to make it so, if necessary. To account for this, the
|
|
rlm@1
|
614 wrapper scripts will output warning lines to standard error that start with
|
|
rlm@1
|
615 "***" whenever they encounter a situation that needs to be reviewed.
|
|
rlm@1
|
616 Following the "***" in the message will be the original command that the
|
|
rlm@1
|
617 installation attempted to perform.
|
|
rlm@1
|
618 You *must* check these "***" lines, examine the affected files or directories
|
|
rlm@1
|
619 and take appropriate action. Because of this it is imperative that you log
|
|
rlm@1
|
620 the messages output during a package installation and check these logs
|
|
rlm@1
|
621 religiously. The `build' script contained in the more_control_helpers archive
|
|
rlm@1
|
622 demonstrates some useful output redirection tricks to be used for this purpose.
|
|
rlm@1
|
623 The following 3 examples shall illustrate what kind of things you will have to
|
|
rlm@1
|
624 look for:
|
|
rlm@1
|
625
|
|
rlm@1
|
626 Example 1: "*** install -c rsh -o root -m 4775 /usr/bin/rsh"
|
|
rlm@1
|
627 This message is output by the install wrapper during the installation of
|
|
rlm@1
|
628 inetutils. The package wants to install the rsh binary setuid root. The
|
|
rlm@1
|
629 install wrapper removes the "-o root" and changes the "-m 4775" to
|
|
rlm@1
|
630 "-m 755" before passing the command on to the real install program.
|
|
rlm@1
|
631 The important thing here is the "-m 4xxx", because this wants to set the
|
|
rlm@1
|
632 setuid bit. Some install scripts throw in a "-o root" for good measure
|
|
rlm@1
|
633 when installing an otherwise normal binary. In that case it's enough that
|
|
rlm@1
|
634 the install wrapper strips out the "-o root" and you don't have to take
|
|
rlm@1
|
635 further action. But when, as in the case of inetutils, the permissions
|
|
rlm@1
|
636 indicate an attempt to make a binary setuid or setgid, then you will have to
|
|
rlm@1
|
637 investigate. You need to decide if you want rsh to be setuid root and
|
|
rlm@1
|
638 if you decide you do, you need to become root and issue commands like this:
|
|
rlm@1
|
639
|
|
rlm@1
|
640 chown root /usr/bin/rsh
|
|
rlm@1
|
641 chmod u+s /usr/bin/rsh
|
|
rlm@1
|
642
|
|
rlm@1
|
643 TIP:
|
|
rlm@1
|
644 Be conservative with making binaries setuid. If you're unsure whether you
|
|
rlm@1
|
645 will ever use a program (as non-root), you probably don't want it to be
|
|
rlm@1
|
646 setuid root. Keep in mind that you can always make the change later when
|
|
rlm@1
|
647 you need it. When you apply this reasoning to rsh, for instance, you'll
|
|
rlm@1
|
648 probably end up not making it setuid root.
|
|
rlm@1
|
649
|
|
rlm@1
|
650
|
|
rlm@1
|
651 Example 2: "*** chgrp tty /usr/bin/write"
|
|
rlm@1
|
652 This is output by the chgrp wrapper during the util-linux installation.
|
|
rlm@1
|
653 The util-linux package wants to install the write program as setgid tty,
|
|
rlm@1
|
654 so that it is allowed to access other users' terminals. The chgrp wrapper
|
|
rlm@1
|
655 prevents the changing of the group and the chmod wrapper prevents the
|
|
rlm@1
|
656 setting of the setgid bit. You need to decide if you want the
|
|
rlm@1
|
657 program to be setgid and if you decide in favor of this, do as root
|
|
rlm@1
|
658
|
|
rlm@1
|
659 chgrp tty /usr/bin/write
|
|
rlm@1
|
660 chmod g+s /usr/bin/write
|
|
rlm@1
|
661
|
|
rlm@1
|
662
|
|
rlm@1
|
663 Example 3: "*** install -d -m 755 /sbin"
|
|
rlm@1
|
664 This is also from the util-linux installation. Util-linux, for no good
|
|
rlm@1
|
665 reason, tries to recreate the /sbin directory. The install wrapper
|
|
rlm@1
|
666 prevents this and you don't have to take any further action.
|
|
rlm@1
|
667
|
|
rlm@1
|
668
|
|
rlm@1
|
669 5.3 add_package_user/install_package
|
|
rlm@1
|
670 ------------------------------------
|
|
rlm@1
|
671
|
|
rlm@1
|
672 Whenever you install a new package on your system, you first have to create
|
|
rlm@1
|
673 a new user account, possibly create a new group and if you follow the advice
|
|
rlm@1
|
674 from this hint about making productive use of a package user's home directory,
|
|
rlm@1
|
675 you will have to set up that one, too. If you were to do all of this manually,
|
|
rlm@1
|
676 it would be a lot of work. The add_package_user and install_package scripts
|
|
rlm@1
|
677 in the more_control_helpers archive were written to automate this.
|
|
rlm@1
|
678
|
|
rlm@1
|
679 The install_package script is the one you will normally use to prepare for
|
|
rlm@1
|
680 installing a new package. It takes 3 parameters: the description of the
|
|
rlm@1
|
681 package, the name of the package user account to create and the name of the
|
|
rlm@1
|
682 package user's primary group. So if you use the user=group scheme recommended
|
|
rlm@1
|
683 by this hint and are as creative with your package descriptions as I am, then
|
|
rlm@1
|
684 the command you'll use to prepare for installing package "foo" will be
|
|
rlm@1
|
685
|
|
rlm@1
|
686 install_package foo foo foo
|
|
rlm@1
|
687
|
|
rlm@1
|
688 This command does 2 things. First it calls the add_package_user script with
|
|
rlm@1
|
689 the provided name, group and description plus sensible default values for
|
|
rlm@1
|
690 add_package_user's other parameters. Then, after add_package_user has created
|
|
rlm@1
|
691 the package user account, install_package automatically uses the su-command
|
|
rlm@1
|
692 to switch to the newly created account. If the default .bashrc and
|
|
rlm@1
|
693 .bash_profile scripts you use for package users contain the command "cd" as do
|
|
rlm@1
|
694 the examples in the more_control_helpers archive, you will be put right into
|
|
rlm@1
|
695 your package user's home directory so that you can start installing right away.
|
|
rlm@1
|
696
|
|
rlm@1
|
697 TIP:
|
|
rlm@1
|
698 The install_package script can be called with a single argument that will
|
|
rlm@1
|
699 be used as user name, group name and description. So instead of the above
|
|
rlm@1
|
700 command a simple `install_package foo' would have sufficed.
|
|
rlm@1
|
701
|
|
rlm@1
|
702 The add_package_user script is responsible for the actual work of creating
|
|
rlm@1
|
703 a new package user account. Given a name, a group name and a description, it
|
|
rlm@1
|
704 will create a new user account with the provided primary group and the install
|
|
rlm@1
|
705 group as supplementary group. The groups will be created if necessary.
|
|
rlm@1
|
706 add_package_user takes several arguments that determine the numeric ranges from
|
|
rlm@1
|
707 which it will pick the new user's UID and the GIDs for groups it needs to
|
|
rlm@1
|
708 create. add_package_user does not only create the package user account. It
|
|
rlm@1
|
709 will set up a home directory for it, too. You can either specify the directory
|
|
rlm@1
|
710 or go with the default, which is /usr/src/<name>, where <name> is the name
|
|
rlm@1
|
711 provided for the new account. If the home directory already exists, its
|
|
rlm@1
|
712 ownership and that of any existing contents will be changed to the new user.
|
|
rlm@1
|
713 If it doesn't exist, it will be created.
|
|
rlm@1
|
714
|
|
rlm@1
|
715 The contents of /etc/pkgusr/skel-package will be copied into the new package
|
|
rlm@1
|
716 user's home directory (without overwriting pre-existing files).
|
|
rlm@1
|
717 The more_control_helpers archive contains an example of a useful skel-package
|
|
rlm@1
|
718 directory. Note that symlinks are copied as symlinks, so skel-package is the
|
|
rlm@1
|
719 perfect place to put .bashrc and .bash_profile symlinks to a central location
|
|
rlm@1
|
720 that will ensure that all package user accounts have the same environment.
|
|
rlm@1
|
721 This is especially useful to make sure that all package users have the
|
|
rlm@1
|
722 wrappers directory in their PATH.
|
|
rlm@1
|
723
|
|
rlm@1
|
724
|
|
rlm@1
|
725 5.4 forall_direntries_from
|
|
rlm@1
|
726 --------------------------
|
|
rlm@1
|
727
|
|
rlm@1
|
728 The forall_direntries_from script is a very useful tool for common package
|
|
rlm@1
|
729 management tasks. It can roughly be described as a shortcut for
|
|
rlm@1
|
730 "find / -user <name> -or -group <name> <commands>", where <name> is the
|
|
rlm@1
|
731 first parameter to forall_direntries_from and <commands> are the remaining
|
|
rlm@1
|
732 parameters. However, forall_direntries_from takes care of making sure that
|
|
rlm@1
|
733 only relevant filesystems are scanned and shields you from certain unpleasant
|
|
rlm@1
|
734 surprises such as "Oops, I forgot that -depth negates -prune and have
|
|
rlm@1
|
735 accidentally wiped out my home directory." or "Oops, I forgot to -prune /proc
|
|
rlm@1
|
736 and now I'm getting parity errors on my SCSI bus.".
|
|
rlm@1
|
737
|
|
rlm@1
|
738 IMPORTANT NOTE: By default the forall_direntries_from script will only scan
|
|
rlm@1
|
739 the / filesystem and will not traverse other filesystems. If you have
|
|
rlm@1
|
740 relevant directories that need to be scanned on other filesystems, you will
|
|
rlm@1
|
741 need to edit the script and add the respective mount point(s) to the
|
|
rlm@1
|
742 fs_to_scan list at the beginning of the script. The most likely candidate for
|
|
rlm@1
|
743 addition is "/usr".
|
|
rlm@1
|
744
|
|
rlm@1
|
745 Application examples:
|
|
rlm@1
|
746
|
|
rlm@1
|
747 Example 1: Create a tar.gz archive of all files that belong to <package>, e.g.
|
|
rlm@1
|
748 for installing <package> on another machine without having to
|
|
rlm@1
|
749 recompile it there.
|
|
rlm@1
|
750
|
|
rlm@1
|
751 forall_direntries_from <package> -fprint0 /tmp/files.lst
|
|
rlm@1
|
752 tar --null -P -czf /tmp/archive.tar.gz --files-from=/tmp/files.lst
|
|
rlm@1
|
753
|
|
rlm@1
|
754
|
|
rlm@1
|
755 Example 2: Print out all setuid root binaries installed by <package>.
|
|
rlm@1
|
756 (This only works if you use the user=group scheme.)
|
|
rlm@1
|
757
|
|
rlm@1
|
758 forall_direntries_from <package> -perm +u+s -print
|
|
rlm@1
|
759
|
|
rlm@1
|
760
|
|
rlm@1
|
761 Example 3: List all binaries in /bin and /usr/bin belonging to "me" (i.e. the
|
|
rlm@1
|
762 package user executing the command) in alphabetical order.
|
|
rlm@1
|
763
|
|
rlm@1
|
764 forall_direntries_from $(whoami) -path "*/bin/*" -printf "%f\n" | sort
|
|
rlm@1
|
765
|
|
rlm@1
|
766
|
|
rlm@1
|
767 Example 4: Uninstall <package>.
|
|
rlm@1
|
768
|
|
rlm@1
|
769 See following section about the uninstall_package script.
|
|
rlm@1
|
770
|
|
rlm@1
|
771
|
|
rlm@1
|
772 5.5 uninstall_package
|
|
rlm@1
|
773 ---------------------
|
|
rlm@1
|
774
|
|
rlm@1
|
775 The uninstall_package script is basically a forall_direntries_from
|
|
rlm@1
|
776 application example in script form. The command `uninstall_package foo'
|
|
rlm@1
|
777 prints out the forall_direntries_from call that you have to use to delete
|
|
rlm@1
|
778 all the files of package "foo" (except for those in directories that
|
|
rlm@1
|
779 forall_direntries_from is instructed not to scan) together with some
|
|
rlm@1
|
780 explanations. So in order to delete the files from package foo, you would
|
|
rlm@1
|
781 execute `uninstall_package foo' and then copy'n'paste the command it prints
|
|
rlm@1
|
782 to the command line. As a safeguard the forall_direntries_from call has an
|
|
rlm@1
|
783 "echo" in front of the "rm" and "rmdir" calls, so if you execute it, the files
|
|
rlm@1
|
784 will not actually be deleted unless you remove both instances of "echo".
|
|
rlm@1
|
785 It is recommended that you execute the command once with the echos and check
|
|
rlm@1
|
786 the output to make sure that only the files you intend to be deleted are in
|
|
rlm@1
|
787 the list. After you've confirmed that, you can use the shell's history to
|
|
rlm@1
|
788 recall the command, edit out the instances of "echo" and remove the files
|
|
rlm@1
|
789 for real.
|
|
rlm@1
|
790
|
|
rlm@1
|
791
|
|
rlm@1
|
792 5.6 list_suspicious_files/list_suspicious_files_from
|
|
rlm@1
|
793 ----------------------------------------------------
|
|
rlm@1
|
794
|
|
rlm@1
|
795 list_suspicious_files looks for filesystem entries that are out of the ordinary
|
|
rlm@1
|
796 in some way and prints a categorized list of them. Things that qualify as
|
|
rlm@1
|
797 suspicious include setuid and setgid binaries, world-writable files, symlinks
|
|
rlm@1
|
798 that are possibly broken, hard links, install directories with unusual
|
|
rlm@1
|
799 permissions and other stuff. You should run this script after you've finished
|
|
rlm@1
|
800 your new LFS system and in regular intervals after that. Investigate the
|
|
rlm@1
|
801 listing closely.
|
|
rlm@1
|
802
|
|
rlm@1
|
803 TIP:
|
|
rlm@1
|
804 When you check the list of setuid and setgid files, don't forget to
|
|
rlm@1
|
805 look at the actual user or group ownership of the file. It's easy to forget
|
|
rlm@1
|
806 that, especially in the setuid case, because we often equate setuid with
|
|
rlm@1
|
807 setuid root since setuid is seldom used with other user accounts.
|
|
rlm@1
|
808
|
|
rlm@1
|
809 list_suspicious_files_from takes a user or group name or a UID/GID as an
|
|
rlm@1
|
810 argument and reports suspicious entries only when they are owned by the given
|
|
rlm@1
|
811 user or group. Usually you would not call this script directly but instead
|
|
rlm@1
|
812 use list_package (described in the next section), whose output includes that
|
|
rlm@1
|
813 from list_suspicious_files_from.
|
|
rlm@1
|
814
|
|
rlm@1
|
815 IMPORTANT NOTE: By default the list_suspicious_files script will only scan
|
|
rlm@1
|
816 the / filesystem and will not traverse other filesystems. If you have
|
|
rlm@1
|
817 relevant directories that need to be scanned on other filesystems, you will
|
|
rlm@1
|
818 need to edit the script and add the respective mount point(s) to the
|
|
rlm@1
|
819 fs_to_scan list at the beginning of the script. The most likely candidate for
|
|
rlm@1
|
820 addition is "/usr".
|
|
rlm@1
|
821
|
|
rlm@1
|
822
|
|
rlm@1
|
823 5.7 list_package
|
|
rlm@1
|
824 ----------------
|
|
rlm@1
|
825
|
|
rlm@1
|
826 list_package tells you everything about a package's installed files. In
|
|
rlm@1
|
827 general you will want to execute something like
|
|
rlm@1
|
828
|
|
rlm@1
|
829 list_package $(whoami) >pkg.lst
|
|
rlm@1
|
830
|
|
rlm@1
|
831 right after installing a package and you can forget about the chronically
|
|
rlm@1
|
832 inaccurate content listings in the (B)LFS book.
|
|
rlm@1
|
833 The following (shortened) output for util-linux speaks for itself:
|
|
rlm@1
|
834
|
|
rlm@1
|
835 PS1> list_package util-linux
|
|
rlm@1
|
836
|
|
rlm@1
|
837 EXECUTABLES (in */bin or */sbin)
|
|
rlm@1
|
838 agetty, arch, blockdev, cal, cfdisk, [...] vidmode(->rdev), whereis, write
|
|
rlm@1
|
839
|
|
rlm@1
|
840 EXECUTABLES WITH NO MANPAGE (in */bin or */sbin)
|
|
rlm@1
|
841 fsck.cramfs, mkfs.cramfs
|
|
rlm@1
|
842
|
|
rlm@1
|
843 MANPAGE SUMMARIES OF EXECUTABLES (in */bin or */sbin)
|
|
rlm@1
|
844 agetty: alternative Linux getty
|
|
rlm@1
|
845 arch: print machine architecture
|
|
rlm@1
|
846 blockdev: call block device ioctls from the command line
|
|
rlm@1
|
847 cal: displays a calendar
|
|
rlm@1
|
848 cfdisk: Curses based disk partition table manipulator for Linux
|
|
rlm@1
|
849 chkdupexe: find duplicate executables
|
|
rlm@1
|
850 col: filter reverse line feeds from input
|
|
rlm@1
|
851 [...]
|
|
rlm@1
|
852 swapon: enable/disable devices and files for paging and swapping
|
|
rlm@1
|
853 tailf: follow the growth of a log file
|
|
rlm@1
|
854 tunelp: set various parameters for the lp device
|
|
rlm@1
|
855 ul: do underlining
|
|
rlm@1
|
856 umount: unmount file systems
|
|
rlm@1
|
857 vidmode: query/set image root device, RAM disk size, or video mode
|
|
rlm@1
|
858 whereis: locate the binary, source, and manual page files for a command
|
|
rlm@1
|
859 write: send a message to another user
|
|
rlm@1
|
860
|
|
rlm@1
|
861 EXTRA MANPAGES
|
|
rlm@1
|
862 /usr/share/man/man5/fstab.5
|
|
rlm@1
|
863 /usr/share/man/man5/nfs.5
|
|
rlm@1
|
864 /usr/share/man/man8/sln.8
|
|
rlm@1
|
865
|
|
rlm@1
|
866 EXTRA EXECUTABLES (not in */bin or */sbin)
|
|
rlm@1
|
867 /usr/share/misc/getopt/getopt-parse.bash
|
|
rlm@1
|
868 /usr/share/misc/getopt/getopt-parse.tcsh
|
|
rlm@1
|
869 /usr/share/misc/getopt/getopt-test.bash
|
|
rlm@1
|
870 /usr/share/misc/getopt/getopt-test.tcsh
|
|
rlm@1
|
871
|
|
rlm@1
|
872 ALL FILES
|
|
rlm@1
|
873 /etc/fdprm
|
|
rlm@1
|
874 /sbin/agetty
|
|
rlm@1
|
875 /sbin/blockdev
|
|
rlm@1
|
876 /sbin/cfdisk
|
|
rlm@1
|
877 /sbin/ctrlaltdel
|
|
rlm@1
|
878 /sbin/elvtune
|
|
rlm@1
|
879 /sbin/fdisk
|
|
rlm@1
|
880 /sbin/fsck.cramfs
|
|
rlm@1
|
881 /sbin/fsck.minix
|
|
rlm@1
|
882 /sbin/hwclock
|
|
rlm@1
|
883 /sbin/losetup
|
|
rlm@1
|
884 /sbin/mkfs
|
|
rlm@1
|
885 /sbin/mkfs.bfs
|
|
rlm@1
|
886 [...]
|
|
rlm@1
|
887 /usr/share/man/man8/rootflags.8
|
|
rlm@1
|
888 /usr/share/man/man8/setfdprm.8
|
|
rlm@1
|
889 /usr/share/man/man8/setsid.8
|
|
rlm@1
|
890 /usr/share/man/man8/sfdisk.8
|
|
rlm@1
|
891 /usr/share/man/man8/sln.8
|
|
rlm@1
|
892 /usr/share/man/man8/swapoff.8
|
|
rlm@1
|
893 /usr/share/man/man8/swapon.8
|
|
rlm@1
|
894 /usr/share/man/man8/tunelp.8
|
|
rlm@1
|
895 /usr/share/man/man8/umount.8
|
|
rlm@1
|
896 /usr/share/man/man8/vidmode.8
|
|
rlm@1
|
897 /usr/share/misc/getopt
|
|
rlm@1
|
898 /usr/share/misc/getopt/getopt-parse.bash
|
|
rlm@1
|
899 /usr/share/misc/getopt/getopt-parse.tcsh
|
|
rlm@1
|
900 /usr/share/misc/getopt/getopt-test.bash
|
|
rlm@1
|
901 /usr/share/misc/getopt/getopt-test.tcsh
|
|
rlm@1
|
902
|
|
rlm@1
|
903 SETUID FILES
|
|
rlm@1
|
904 -rwsr-xr-x "/usr/bin/mount" root:util-linux
|
|
rlm@1
|
905 -rwsr-xr-x "/usr/bin/umount" root:util-linux
|
|
rlm@1
|
906
|
|
rlm@1
|
907 SETGID FILES
|
|
rlm@1
|
908 -rwxr-sr-x "/usr/bin/write" util-linux:tty
|
|
rlm@1
|
909
|
|
rlm@1
|
910 FILES WITH UNUSUAL PERMISSIONS
|
|
rlm@1
|
911 -rwsr-xr-x "/usr/bin/mount" root:util-linux
|
|
rlm@1
|
912 -rwsr-xr-x "/usr/bin/umount" root:util-linux
|
|
rlm@1
|
913 -rwxr-sr-x "/usr/bin/write" util-linux:tty
|
|
rlm@1
|
914
|
|
rlm@1
|
915
|
|
rlm@1
|
916 Note: list_package works regardless of the prefix you've installed the package
|
|
rlm@1
|
917 with, so you can for instance configure with --prefix=/opt/package and
|
|
rlm@1
|
918 list_package will work just fine (provided that /opt is on a
|
|
rlm@1
|
919 filesystem configured to be scanned by forall_direntries_from and
|
|
rlm@1
|
920 list_suspicious_files).
|
|
rlm@1
|
921
|
|
rlm@1
|
922 Note: list_package only considers manpages actually owned by the package to
|
|
rlm@1
|
923 list. It will not consider manpages installed by another package. This
|
|
rlm@1
|
924 means that you may see executables identified as not having a manpage
|
|
rlm@1
|
925 although they do have one courtesy of another package
|
|
rlm@1
|
926 (usually man-pages).
|
|
rlm@1
|
927
|
|
rlm@1
|
928
|
|
rlm@1
|
929 5.8 grep_all_regular_files_for
|
|
rlm@1
|
930 ------------------------------
|
|
rlm@1
|
931
|
|
rlm@1
|
932 This script is not really related to the package user system, but because of
|
|
rlm@1
|
933 its similarity to the other scripts I've included it anyway. The sole purpose
|
|
rlm@1
|
934 of this script is to identify files that store references to the build
|
|
rlm@1
|
935 environment, specifically the /tools directory. Such references may point out
|
|
rlm@1
|
936 problems, since the /tools directory is supposed to be transient.
|
|
rlm@1
|
937 Don't forget that results for unstripped binaries and libraries are not
|
|
rlm@1
|
938 reliable, because debugging information often includes references to the
|
|
rlm@1
|
939 build environment. These do not cause trouble (unless you're trying to debug
|
|
rlm@1
|
940 the objects in question after deleting /tools).
|
|
rlm@1
|
941
|
|
rlm@1
|
942 IMPORTANT NOTE: By default the grep_all_regular_files_for script will only scan
|
|
rlm@1
|
943 the / filesystem and will not traverse other filesystems. If you have
|
|
rlm@1
|
944 relevant directories that need to be scanned on other filesystems, you will
|
|
rlm@1
|
945 need to edit the script and add the respective mount point(s) to the
|
|
rlm@1
|
946 fs_to_scan list at the beginning of the script. The most likely candidate for
|
|
rlm@1
|
947 addition is "/usr".
|
|
rlm@1
|
948
|
|
rlm@1
|
949
|
|
rlm@1
|
950 5.9 The etc Directory
|
|
rlm@1
|
951 ---------------------
|
|
rlm@1
|
952
|
|
rlm@1
|
953 If you follow the instructions provided in the LFS-specific part of this hint,
|
|
rlm@1
|
954 the contents of the etc directory will be installed in /etc/pkgusr. The
|
|
rlm@1
|
955 directory contains a bashrc and bash_profile for package users that takes
|
|
rlm@1
|
956 care of package user specific details such as putting the wrappers directory
|
|
rlm@1
|
957 at the beginning of the PATH and calling cd, so that `su <package>' will
|
|
rlm@1
|
958 put you right into the package user's home directory. Also contained in the
|
|
rlm@1
|
959 etc directory is a skel-package directory as used by
|
|
rlm@1
|
960 install_package/add_package_user to populate the home directories of newly
|
|
rlm@1
|
961 created package users.
|
|
rlm@1
|
962
|
|
rlm@1
|
963
|
|
rlm@1
|
964 5.10 ldconfig.c
|
|
rlm@1
|
965 --------------------
|
|
rlm@1
|
966
|
|
rlm@1
|
967 A lot of packages contain libraries. Having to manually call /sbin/ldconfig
|
|
rlm@1
|
968 as root after installing these packages can become annoying. It would be
|
|
rlm@1
|
969 much easier if one could grant package users permission to use /sbin/ldconfig.
|
|
rlm@1
|
970 Making ldconfig setuid root would be a simple and effective solution, but
|
|
rlm@1
|
971 there are some pitfalls. First of all it is imperative that ordinary users
|
|
rlm@1
|
972 be prohibited from executing ldconfig with elevated privileges. Otherwise
|
|
rlm@1
|
973 an ordinary user can overwrite and possibly read arbitrary files on the
|
|
rlm@1
|
974 system. This can be prevented by making ldconfig owned by group install and
|
|
rlm@1
|
975 removing the o+x bit from the file mode. While this setup is no less secure
|
|
rlm@1
|
976 than running `make install' as root, one reason why we're using package users
|
|
rlm@1
|
977 is because we don't feel safe doing that. To protect against the (admittedly
|
|
rlm@1
|
978 very theoretical) danger of a malicious package user, the more_control_helpers
|
|
rlm@1
|
979 provide ldconfig.c. The only thing this program does is to call
|
|
rlm@1
|
980 `/sbin/ldconfig -v' with an empty environment. Because it doesn't evaluate
|
|
rlm@1
|
981 any user input and doesn't pass any user-provided data to ldconfig, it can
|
|
rlm@1
|
982 safely be made setuid root.
|
|
rlm@1
|
983
|
|
rlm@1
|
984
|
|
rlm@1
|
985 5.11 Temporary Files
|
|
rlm@1
|
986 --------------------
|
|
rlm@1
|
987
|
|
rlm@1
|
988 3 files in the more_control_helpers archive are only used during the
|
|
rlm@1
|
989 installation of the base LFS system and are not installed permanently.
|
|
rlm@1
|
990 The first of them is the installdirs.lst file that contains a list of
|
|
rlm@1
|
991 directories that should be install directories.
|
|
rlm@1
|
992 The second file is sbin/useradd, which is a very primitive shell script that
|
|
rlm@1
|
993 adds a new entry to /etc/passwd. It allows us to add package users before
|
|
rlm@1
|
994 we have installed shadow, which provides a real useradd.
|
|
rlm@1
|
995 Finally there is groupadd, which is like useradd, only for /etc/group.
|
|
rlm@1
|
996 Both scripts, useradd as well as groupadd, do very little error checking and
|
|
rlm@1
|
997 only support the syntax needed by install_package/add_package_user. So don't
|
|
rlm@1
|
998 try anything funky with them.
|
|
rlm@1
|
999
|
|
rlm@1
|
1000
|
|
rlm@1
|
1001 ------------------------ PART 2: LFS Specifics ------------------------------
|
|
rlm@1
|
1002
|
|
rlm@1
|
1003
|
|
rlm@1
|
1004 #############################################################################
|
|
rlm@1
|
1005 6. Pre-Chroot Phase (Chapter 5)
|
|
rlm@1
|
1006 #############################################################################
|
|
rlm@1
|
1007
|
|
rlm@1
|
1008 Build Chapter 5 explained by the LFS book with the following changes:
|
|
rlm@1
|
1009
|
|
rlm@1
|
1010 coreutils:
|
|
rlm@1
|
1011 After running `make install' for the coreutils
|
|
rlm@1
|
1012 package, issue the following command (still from within the coreutils
|
|
rlm@1
|
1013 build directory):
|
|
rlm@1
|
1014
|
|
rlm@1
|
1015 cp src/su /tools/bin
|
|
rlm@1
|
1016
|
|
rlm@1
|
1017 This installs the su binary. Coreutils doesn't install su when working as
|
|
rlm@1
|
1018 non-root (which we do in Chapter 5), because su needs to be setuid root for
|
|
rlm@1
|
1019 normal operation and a non-root user cannot install setuid root binaries.
|
|
rlm@1
|
1020 But for our purposes (i.e. su'ing from root to a package user) a non-setuid
|
|
rlm@1
|
1021 su is enough, so we just copy coreutils' su to /tools/bin without making it
|
|
rlm@1
|
1022 setuid root.
|
|
rlm@1
|
1023
|
|
rlm@1
|
1024 more_control_helpers:
|
|
rlm@1
|
1025 When you have reached the end of Chapter 5, before you begin with Chapter 6
|
|
rlm@1
|
1026 you will need to install the helper scripts in the /tools directory so that
|
|
rlm@1
|
1027 they are available once you've entered the chroot environment. Use the
|
|
rlm@1
|
1028 following commands to install the more_control_helpers in /tools:
|
|
rlm@1
|
1029
|
|
rlm@1
|
1030 cd /tools &&
|
|
rlm@1
|
1031 tar xjf /path/to/more_control_helpers.tar.bz2 &&
|
|
rlm@1
|
1032 cd more_control_helpers &&
|
|
rlm@1
|
1033 cp ./sbin/* /tools/bin
|
|
rlm@1
|
1034
|
|
rlm@1
|
1035 Note that the target directory is "/tools/bin" in the cp command and
|
|
rlm@1
|
1036 *not* "/tools/sbin", although the latter location would be more appropriate.
|
|
rlm@1
|
1037 The reason for this is simply that the LFS instructions do not add
|
|
rlm@1
|
1038 "/tools/sbin" to the PATH (and neither do the instructions in this hint).
|
|
rlm@1
|
1039
|
|
rlm@1
|
1040
|
|
rlm@1
|
1041 #############################################################################
|
|
rlm@1
|
1042 7. Chroot Phase (Chapter 6)
|
|
rlm@1
|
1043 #############################################################################
|
|
rlm@1
|
1044
|
|
rlm@1
|
1045 7.1 Preparations
|
|
rlm@1
|
1046 ----------------
|
|
rlm@1
|
1047
|
|
rlm@1
|
1048 Enter the chroot environment and follow the instructions from the book up to
|
|
rlm@1
|
1049 but *not* including the installation of the first package (which at the time of
|
|
rlm@1
|
1050 this writing is linux-libc-headers). Now install the more_control_helpers
|
|
rlm@1
|
1051 files in their proper locations on the new LFS system:
|
|
rlm@1
|
1052
|
|
rlm@1
|
1053 cp -a /tools/more_control_helpers/etc /etc/pkgusr &&
|
|
rlm@1
|
1054 chown -R 0:0 /etc/pkgusr &&
|
|
rlm@1
|
1055 cp -a /tools/more_control_helpers/lib /usr/lib/pkgusr &&
|
|
rlm@1
|
1056 chown -R 0:0 /usr/lib/pkgusr &&
|
|
rlm@1
|
1057 cp /tools/more_control_helpers/bin/* /usr/bin &&
|
|
rlm@1
|
1058 cp /tools/more_control_helpers/sbin/* /usr/sbin &&
|
|
rlm@1
|
1059 rm /usr/sbin/{useradd,groupadd}
|
|
rlm@1
|
1060
|
|
rlm@1
|
1061 Note that the useradd and groupadd scripts are not installed on the new LFS
|
|
rlm@1
|
1062 system. These scripts are just temporary workarounds we will use as long as
|
|
rlm@1
|
1063 the real useradd and groupadd are not available. Therefore they should only
|
|
rlm@1
|
1064 be in /tools/bin.
|
|
rlm@1
|
1065
|
|
rlm@1
|
1066 ATTENTION! If you decide to use a different directory than /usr/lib/pkgusr
|
|
rlm@1
|
1067 for the wrappers, you have to be careful, because at least the glibc
|
|
rlm@1
|
1068 configure script ignores certain directories when looking for programs. The
|
|
rlm@1
|
1069 list of ignored directories for glibc includes, among others, everything that
|
|
rlm@1
|
1070 starts with "/etc", "/usr/etc" and "/sbin". Wrappers put into a directory that
|
|
rlm@1
|
1071 matches any of these patterns would be ineffective.
|
|
rlm@1
|
1072
|
|
rlm@1
|
1073 Now it's time to create the install group:
|
|
rlm@1
|
1074
|
|
rlm@1
|
1075 groupadd -g 9999 install
|
|
rlm@1
|
1076
|
|
rlm@1
|
1077 The GID 9999 has been chosen because the default range used by
|
|
rlm@1
|
1078 add_package_user for package user GIDs starts at 10000. Choose whatever number
|
|
rlm@1
|
1079 you like.
|
|
rlm@1
|
1080
|
|
rlm@1
|
1081 Once the install group has been created you have to turn all the directories
|
|
rlm@1
|
1082 that packages will install files in into install directories. To make this
|
|
rlm@1
|
1083 easier I have compiled a list of install directories that can be found in
|
|
rlm@1
|
1084 the file /tools/more_control_helpers/installdirs.lst. The following command
|
|
rlm@1
|
1085 uses this list to assign the necessary directories to the install group.
|
|
rlm@1
|
1086 Note that you will get several error messages because of non-existent
|
|
rlm@1
|
1087 directories. This is because the list contains some directories not created
|
|
rlm@1
|
1088 by LFS.
|
|
rlm@1
|
1089
|
|
rlm@1
|
1090 chown 0:9999 $(cat /tools/more_control_helpers/installdirs.lst)
|
|
rlm@1
|
1091
|
|
rlm@1
|
1092 To be usable by package users, the directories will have to be group-writable
|
|
rlm@1
|
1093 and should be sticky as has been explained in the beginning of this hint.
|
|
rlm@1
|
1094 The following command sets the permissions appropriately.
|
|
rlm@1
|
1095 You will get the same error messages as for the previous command.
|
|
rlm@1
|
1096
|
|
rlm@1
|
1097 chmod ug=rwx,o=rxt $(cat /tools/more_control_helpers/installdirs.lst)
|
|
rlm@1
|
1098
|
|
rlm@1
|
1099
|
|
rlm@1
|
1100 7.2 Walkthrough: Installing linux-libc-headers
|
|
rlm@1
|
1101 ----------------------------------------------
|
|
rlm@1
|
1102
|
|
rlm@1
|
1103 At this point everything has been set up for creating the first package
|
|
rlm@1
|
1104 user. At the time of this writing the first package installed in the LFS
|
|
rlm@1
|
1105 book is Linux-Libc-Headers, so this package will serve as an example for how
|
|
rlm@1
|
1106 things are done. The command
|
|
rlm@1
|
1107
|
|
rlm@1
|
1108 install_package 'Linux Headers' linux-libc-headers linux-libc-headers
|
|
rlm@1
|
1109
|
|
rlm@1
|
1110 will create a package user with user and group name linux-libc-headers.
|
|
rlm@1
|
1111 If you don't want to use the user=group scheme, change the last argument to
|
|
rlm@1
|
1112 the desired group name. The description is arbitrary but needs to meet the
|
|
rlm@1
|
1113 requirements for the description field of an /etc/passwd entry.
|
|
rlm@1
|
1114
|
|
rlm@1
|
1115 TIP:
|
|
rlm@1
|
1116 Remember that you can call install_package with just one argument, if you
|
|
rlm@1
|
1117 want user name, group name and description to be the same.
|
|
rlm@1
|
1118
|
|
rlm@1
|
1119 The directory /usr/src/linux-libc-headers will be set up as the home directory
|
|
rlm@1
|
1120 for the package user, automatically populated with the contents of
|
|
rlm@1
|
1121 /etc/pkgusr/skel-package. The install_package command also issues the command
|
|
rlm@1
|
1122 `su - linux-libc-headers' to assume the identity of the newly created package
|
|
rlm@1
|
1123 user. If you're using the bashrc and bash_profile scripts from the
|
|
rlm@1
|
1124 more_control_helpers archive, you will be put straight into the directory
|
|
rlm@1
|
1125 /usr/src/linux-libc-headers and your prompt will look like this
|
|
rlm@1
|
1126
|
|
rlm@1
|
1127 package linux-libc-headers:/usr/src/linux-libc-headers>
|
|
rlm@1
|
1128
|
|
rlm@1
|
1129 to show you that you're working as package user linux-libc-headers and
|
|
rlm@1
|
1130 that your current working directory is /usr/src/linux-libc-headers.
|
|
rlm@1
|
1131
|
|
rlm@1
|
1132 Use the command
|
|
rlm@1
|
1133
|
|
rlm@1
|
1134 echo $PATH
|
|
rlm@1
|
1135
|
|
rlm@1
|
1136 to verify that your PATH starts with "/usr/lib/pkgusr", the directory that
|
|
rlm@1
|
1137 contains the wrappers, and ends with "/tools/bin".
|
|
rlm@1
|
1138
|
|
rlm@1
|
1139 Now everything is prepared for installing the package according to the
|
|
rlm@1
|
1140 instructions in the LFS book. Note that at the time of this writing the
|
|
rlm@1
|
1141 LFS book tells you to execute a chown command to make sure that the headers
|
|
rlm@1
|
1142 are owned by root. This is just because the packager has made a very common
|
|
rlm@1
|
1143 mistake when creating the tarball for the headers: He has archived the files
|
|
rlm@1
|
1144 with a non-root user/group assignment. When unpacking such a tarball as root,
|
|
rlm@1
|
1145 the files end up being owned by some weird user/group combination, which may
|
|
rlm@1
|
1146 open a security hole. When you're working as a package user this can not
|
|
rlm@1
|
1147 happen and you don't want to chown the headers to root:root, because that
|
|
rlm@1
|
1148 would defeat the whole point of installing the headers with a package user.
|
|
rlm@1
|
1149 This is one of the small points on which you will have to deviate from the
|
|
rlm@1
|
1150 standard LFS instructions when using package users. More package user related
|
|
rlm@1
|
1151 issues with the current LFS book can be found in the next section.
|
|
rlm@1
|
1152
|
|
rlm@1
|
1153 After you've installed the headers, simply issue the command
|
|
rlm@1
|
1154
|
|
rlm@1
|
1155 exit
|
|
rlm@1
|
1156
|
|
rlm@1
|
1157 to become root again. Now would be a good time to think about useful
|
|
rlm@1
|
1158 customizations for /etc/pkgusr/{bash_profile,bashrc} and/or
|
|
rlm@1
|
1159 /etc/pkgusr/skel-package, if you've not already customized them.
|
|
rlm@1
|
1160 Once you're satisfied with your setup, install the rest of the packages.
|
|
rlm@1
|
1161 The following section will help you with some problems that you will run into.
|
|
rlm@1
|
1162
|
|
rlm@1
|
1163
|
|
rlm@1
|
1164 7.3 Known Issues with LFS Packages
|
|
rlm@1
|
1165 ----------------------------------
|
|
rlm@1
|
1166
|
|
rlm@1
|
1167 This section has details on the package user related problems you will face
|
|
rlm@1
|
1168 when building your LFS system. You should copy the information from this
|
|
rlm@1
|
1169 section to the INSTALL NOTES of the relevant .project files for the packages
|
|
rlm@1
|
1170 concerned, together with any of your own notes.
|
|
rlm@1
|
1171
|
|
rlm@1
|
1172 NOTE: If you're building by an LFS book later than 6.2 it is recommended that
|
|
rlm@1
|
1173 you read this complete chapter before you start building any packages.
|
|
rlm@1
|
1174 If your LFS version is 6.2 then it's fine to read this section package
|
|
rlm@1
|
1175 by package as you progress with your build.
|
|
rlm@1
|
1176
|
|
rlm@1
|
1177
|
|
rlm@1
|
1178 linux-libc-headers:
|
|
rlm@1
|
1179 At the time of this writing the LFS book tells you to execute a chown
|
|
rlm@1
|
1180 command to make sure that the headers are owned by root. This is just
|
|
rlm@1
|
1181 because the packager has made a very common mistake when creating the
|
|
rlm@1
|
1182 tarball for the headers: He has archived the files with a non-root
|
|
rlm@1
|
1183 user/group assignment. When unpacking such a tarball as root, the files
|
|
rlm@1
|
1184 end up being owned by some weird user/group combination, which may open
|
|
rlm@1
|
1185 a security hole. When you're working as a package user this can not happen
|
|
rlm@1
|
1186 and you don't want to chown the headers to root:root, because that would
|
|
rlm@1
|
1187 defeat the whole point of installing the headers with a package user.
|
|
rlm@1
|
1188
|
|
rlm@1
|
1189 There used to be another packaging error in the linux-libc-headers.
|
|
rlm@1
|
1190 Version 2.6.12.0 (current as of this writing) doesn't have it anymore,
|
|
rlm@1
|
1191 but older versions used to contain files with permissions set incorrectly.
|
|
rlm@1
|
1192 All headers are supposed to be world-readable, but they weren't. More about
|
|
rlm@1
|
1193 this later in the glibc notes.
|
|
rlm@1
|
1194
|
|
rlm@1
|
1195
|
|
rlm@1
|
1196 man-pages:
|
|
rlm@1
|
1197 If the name you use for the man-pages package user is not exactly
|
|
rlm@1
|
1198 "man-pages", then you will have to change the variable "manpagesowner"
|
|
rlm@1
|
1199 right at the beginning of the wrapper script `install'.
|
|
rlm@1
|
1200
|
|
rlm@1
|
1201 Recent versions of man-pages contain POSIX manpages that the package
|
|
rlm@1
|
1202 tries to install in /usr/share/man/man{0,1,3}p. There's also a manpage
|
|
rlm@1
|
1203 that man-pages wants to install to /usr/share/man/man9.
|
|
rlm@1
|
1204 As /usr/share/man is
|
|
rlm@1
|
1205 not an install directory and the LFS book does not have instructions to
|
|
rlm@1
|
1206 create these directories at the time of this writing, the installation
|
|
rlm@1
|
1207 will fail and the respective man-pages will not be installed.
|
|
rlm@1
|
1208 Possible remedies:
|
|
rlm@1
|
1209 1. Make /usr/share/man an install directory.
|
|
rlm@1
|
1210 Consequence: All Packages will be able to create new subdirectories
|
|
rlm@1
|
1211 in /usr/share/man. I find this undesirable because there are packages
|
|
rlm@1
|
1212 that create directories for manpages in foreign languages that I
|
|
rlm@1
|
1213 don't want. YMMV.
|
|
rlm@1
|
1214 2. Ignore the problem and live without the POSIX manpages. Unless
|
|
rlm@1
|
1215 you are a developer (including script writer) who is interested
|
|
rlm@1
|
1216 in writing portable programs/scripts this is a good solution.
|
|
rlm@1
|
1217 3. Create the directories /usr/share/man/man{0,1,3}p and man9 as root
|
|
rlm@1
|
1218 prior to installing man-pages. You'll have to either chown them
|
|
rlm@1
|
1219 to the man-pages package user or make them install directories.
|
|
rlm@1
|
1220 This is my preferred solution.
|
|
rlm@1
|
1221
|
|
rlm@1
|
1222
|
|
rlm@1
|
1223 glibc:
|
|
rlm@1
|
1224 It is kind of unfortunate that the packaging error of libc-linux-headers
|
|
rlm@1
|
1225 concerning the permissions doesn't exist in the current version. It
|
|
rlm@1
|
1226 provided for a great learning experience. I've kept the following section
|
|
rlm@1
|
1227 in the hint for this reason even though it doesn't apply anymore. Please
|
|
rlm@1
|
1228 take the time to read it.
|
|
rlm@1
|
1229
|
|
rlm@1
|
1230 --------------------- old stuff start ----------------------------------------
|
|
rlm@1
|
1231 Because of the error, the headers in /tools/include
|
|
rlm@1
|
1232 are not world-readable. Unfortunately the LFS book (as of this writing)
|
|
rlm@1
|
1233 does not correct this in Chapter 5 like it does in Chapter 6. For a
|
|
rlm@1
|
1234 standard LFS build this is no problem, because glibc is built as root and
|
|
rlm@1
|
1235 root can access everything regardless of permissions.
|
|
rlm@1
|
1236 The glibc package user, however, does not have permission to access
|
|
rlm@1
|
1237 these headers. This will cause several configure tests to fail, because
|
|
rlm@1
|
1238 the respective test programs can not be compiled.
|
|
rlm@1
|
1239 The end result is the error message "/lib/cpp fails sanity check", which
|
|
rlm@1
|
1240 is completely nonsensical as we don't have a /lib/cpp.
|
|
rlm@1
|
1241
|
|
rlm@1
|
1242 This is the perfect opportunity to introduce rule #1 of error diagnostics:
|
|
rlm@1
|
1243
|
|
rlm@1
|
1244 NEVER TRUST DIAGNOSTIC MESSAGES !
|
|
rlm@1
|
1245
|
|
rlm@1
|
1246 There are 2 kinds of diagnostic messages:
|
|
rlm@1
|
1247
|
|
rlm@1
|
1248 1. Those that are unnecessary, because once you see which component has
|
|
rlm@1
|
1249 failed, the source of the problem is obvious.
|
|
rlm@1
|
1250 2. Those that grossly misdiagnose the source of the problem and lead
|
|
rlm@1
|
1251 you to draw the wrong conclusions.
|
|
rlm@1
|
1252
|
|
rlm@1
|
1253 No, there is no other kind. Trust me ;-)
|
|
rlm@1
|
1254 In this case, /lib/cpp has nothing to do with the problem. It doesn't
|
|
rlm@1
|
1255 exist and that's fine. The message just wants to trick you into doing
|
|
rlm@1
|
1256 something stupid such as create a symlink /lib/cpp -> /tools/bin/cpp.
|
|
rlm@1
|
1257 But that would be totally wrong. Before you jump to any premature
|
|
rlm@1
|
1258 conclusions you should always try to get as much *low-level* information
|
|
rlm@1
|
1259 as you can. Diagnostic messages are *high-level* information. They
|
|
rlm@1
|
1260 represent a filtered view of the problem, which is usually of little help.
|
|
rlm@1
|
1261 Fortunately the message (the complete one, not the part quoted above) also
|
|
rlm@1
|
1262 points at the source for the necessary low-level information. In this
|
|
rlm@1
|
1263 case that is the file config.log (not to be confused with configure.log,
|
|
rlm@1
|
1264 the file created by the build script included in the more_control_helpers
|
|
rlm@1
|
1265 archive).
|
|
rlm@1
|
1266 config.log is created by all autoconf-created configures (not just that
|
|
rlm@1
|
1267 of glibc) and it contains, among other things, the test programs used by
|
|
rlm@1
|
1268 configure and messages output while building and running them. Whenever a
|
|
rlm@1
|
1269 configure script fails or gives weird results, check config.log. And
|
|
rlm@1
|
1270 always remember rule #2 of error diagnostics
|
|
rlm@1
|
1271
|
|
rlm@1
|
1272 ALWAYS START AT THE FIRST ERROR
|
|
rlm@1
|
1273
|
|
rlm@1
|
1274 This seems pretty obvious, but nevertheless people commonly do the exact
|
|
rlm@1
|
1275 opposite. It's just too tempting to start at the point of the final
|
|
rlm@1
|
1276 failure and try to work backwards. In this case many people would open
|
|
rlm@1
|
1277 config.log and scroll to the point of the failed /lib/cpp sanity check.
|
|
rlm@1
|
1278 After all, that's what caused configure to abort and so that's what needs
|
|
rlm@1
|
1279 to be fixed, right? WRONG! Someone who takes this approach just sees the
|
|
rlm@1
|
1280 error message "/lib/cpp: No such file or directory" and is even more
|
|
rlm@1
|
1281 convinced that a missing /lib/cpp symlink (or program) is the problem.
|
|
rlm@1
|
1282
|
|
rlm@1
|
1283 The correct way to approach such a problem is to start at the beginning
|
|
rlm@1
|
1284 of config.log, to scroll down to first error message and to check if it
|
|
rlm@1
|
1285 is an issue that needs to be fixed (error messages in config.log are
|
|
rlm@1
|
1286 not always signs for a problem). If the issue needs to be fixed, then
|
|
rlm@1
|
1287 it needs to be fixed first, because all later errors could be rooted in
|
|
rlm@1
|
1288 this issue (even if, no, *especially* if you don't believe this is the
|
|
rlm@1
|
1289 case).
|
|
rlm@1
|
1290 If we apply this advice to the problem at hand, we quickly get to the first
|
|
rlm@1
|
1291 serious error in config.log:
|
|
rlm@1
|
1292
|
|
rlm@1
|
1293 "/tools/include/linux/limits.h: Permission denied"
|
|
rlm@1
|
1294
|
|
rlm@1
|
1295 A quick check with ls reveals that indeed the directory with the linux
|
|
rlm@1
|
1296 headers is not world-readable, which is obviously wrong. The fix is
|
|
rlm@1
|
1297 easy. Just make (as root) the header directories /tools/include/{linux,asm}
|
|
rlm@1
|
1298 world-readable with commands similar to those the LFS book presents
|
|
rlm@1
|
1299 in Chapter 6 for the installation of linux-libc-headers.
|
|
rlm@1
|
1300 Once this change has been made, glibc's configure succeeds.
|
|
rlm@1
|
1301 --------------------- old stuff end -----------------------------------------
|
|
rlm@1
|
1302
|
|
rlm@1
|
1303 TIP:
|
|
rlm@1
|
1304 Even when configure completes successfully, you should still check the
|
|
rlm@1
|
1305 output carefully to see if there is anything odd. E.g. if you're using
|
|
rlm@1
|
1306 the wrappers, you should check that configure outputs the line
|
|
rlm@1
|
1307
|
|
rlm@1
|
1308 checking for a BSD-compatible install... /usr/lib/pkgusr/install -c
|
|
rlm@1
|
1309
|
|
rlm@1
|
1310 If configure detects a different install, such as /tools/bin/install,
|
|
rlm@1
|
1311 something is wrong. Maybe there's a typo in the PATH for the package
|
|
rlm@1
|
1312 user, or you've put the wrappers into a directory that is ignored by
|
|
rlm@1
|
1313 configure.
|
|
rlm@1
|
1314
|
|
rlm@1
|
1315
|
|
rlm@1
|
1316 With the wrappers the glibc build and install should work smoothly.
|
|
rlm@1
|
1317 The wrapper script for install makes sure that the /usr/share/locale/*
|
|
rlm@1
|
1318 directories become install directories so that other programs can install
|
|
rlm@1
|
1319 their localized messages.
|
|
rlm@1
|
1320 One thing that the wrappers do not take care of,
|
|
rlm@1
|
1321 however, is the file /usr/share/info/dir. Because in the current LFS build
|
|
rlm@1
|
1322 order glibc is the first package that installs info files, dir is owned by
|
|
rlm@1
|
1323 and only writable by glibc. In order to allow other packages to install
|
|
rlm@1
|
1324 info pages, execute the following commands as root:
|
|
rlm@1
|
1325
|
|
rlm@1
|
1326 chown root:install /usr/share/info/dir &&
|
|
rlm@1
|
1327 chmod ug=rw,o=r /usr/share/info/dir
|
|
rlm@1
|
1328
|
|
rlm@1
|
1329 NOTE:
|
|
rlm@1
|
1330 glibc wants to install the program pt_chown as setuid root. If you install
|
|
rlm@1
|
1331 as a package user, the program will get installed but not given root
|
|
rlm@1
|
1332 privileges (because of the install wrapper).
|
|
rlm@1
|
1333 The following info is from the glibc docs:
|
|
rlm@1
|
1334
|
|
rlm@1
|
1335 One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
|
|
rlm@1
|
1336 `root'. This program is invoked by the `grantpt' function; it sets the
|
|
rlm@1
|
1337 permissions on a pseudoterminal so it can be used by the calling
|
|
rlm@1
|
1338 process. This means programs like `xterm' and `screen' do not have to
|
|
rlm@1
|
1339 be setuid to get a pty. (There may be other reasons why they need
|
|
rlm@1
|
1340 privileges.) If you are using a 2.1 or newer Linux kernel with the
|
|
rlm@1
|
1341 `devptsfs' or `devfs' filesystems providing pty slaves, you don't need
|
|
rlm@1
|
1342 this program; otherwise you do. The source for `pt_chown' is in
|
|
rlm@1
|
1343 `login/programs/pt_chown.c'.
|
|
rlm@1
|
1344
|
|
rlm@1
|
1345 So unless you're building a system that does not use devpts (which would
|
|
rlm@1
|
1346 be quite unusual), this does not need to concern you.
|
|
rlm@1
|
1347
|
|
rlm@1
|
1348 TIP:
|
|
rlm@1
|
1349 In case you were wondering if you should create /etc/nsswitch.conf and
|
|
rlm@1
|
1350 /etc/ld.so.conf as root or glibc, I recommend to assign all files that
|
|
rlm@1
|
1351 you manually create or manually edit to the root account. That way you can
|
|
rlm@1
|
1352 distinguish between those files that can be regenerated automatically and
|
|
rlm@1
|
1353 those that can not. Assigning even automatically generated files to
|
|
rlm@1
|
1354 root once you make the first manual edit, ensures that a later
|
|
rlm@1
|
1355 reinstallation of a package won't silently do away with your manual tweaks.
|
|
rlm@1
|
1356
|
|
rlm@1
|
1357 ldconfig:
|
|
rlm@1
|
1358 Now that glibc has installed /sbin/ldconfig you can activate the ldconfig
|
|
rlm@1
|
1359 wrapper if you want to. Perform the following steps as root
|
|
rlm@1
|
1360 AFTER re-adjusting the toolchain,
|
|
rlm@1
|
1361 just before starting with binutils:
|
|
rlm@1
|
1362
|
|
rlm@1
|
1363 cd /usr/lib/pkgusr
|
|
rlm@1
|
1364 gcc -O2 -W -Wall -o ldconfig ldconfig.c
|
|
rlm@1
|
1365 chown root:install ldconfig
|
|
rlm@1
|
1366 chmod u=rwxs,g=rxs,o= ldconfig
|
|
rlm@1
|
1367
|
|
rlm@1
|
1368 These instructions make the ldconfig wrapper setuid root and setgid install
|
|
rlm@1
|
1369 and prevent non-root users not in the install group from executing it.
|
|
rlm@1
|
1370 The setuid root is required so that it can replace /etc/ld.so.cache.
|
|
rlm@1
|
1371 The setgid install is not strictly required, but without it
|
|
rlm@1
|
1372 /etc/ld.so.cache will end up with the group of the last package user that
|
|
rlm@1
|
1373 touched it. If you use the user name=group name scheme this will cause the
|
|
rlm@1
|
1374 more_control_helpers scripts to believe that /etc/ld.so.cache belongs to
|
|
rlm@1
|
1375 the package in question which can be confusing.
|
|
rlm@1
|
1376
|
|
rlm@1
|
1377 binutils:
|
|
rlm@1
|
1378 Have you make /usr/share/info/dir group-writable as explained above in
|
|
rlm@1
|
1379 the glibc notes? If you've missed that part, go back and do it now.
|
|
rlm@1
|
1380 The installation of binutils should complete without problems.
|
|
rlm@1
|
1381 It does however cause minor conflicts with autoconf (see later).
|
|
rlm@1
|
1382
|
|
rlm@1
|
1383 NOTE:
|
|
rlm@1
|
1384 At the time of this writing the version of bash used in the LFS book has
|
|
rlm@1
|
1385 a bug that causes the list_package script to spit out errors and to list
|
|
rlm@1
|
1386 all manpages of binutils (and other packages) as Broken. This bug is
|
|
rlm@1
|
1387 already fixed by the bash patch used by the book but the patch is not
|
|
rlm@1
|
1388 applied in chapter 5. Since the manpage summary functionality of
|
|
rlm@1
|
1389 list_package requires man which is not installed until after bash is
|
|
rlm@1
|
1390 rebuilt, this doesn't really matter, because while patching the
|
|
rlm@1
|
1391 chapter 5 bash would get rid of the error messages, it wouldn't result
|
|
rlm@1
|
1392 in usable manpage summaries.
|
|
rlm@1
|
1393
|
|
rlm@1
|
1394
|
|
rlm@1
|
1395 gcc:
|
|
rlm@1
|
1396 Because the /usr/lib/libgcc_s.so* symlinks created at the beginning of
|
|
rlm@1
|
1397 Chapter 6 is owned by root, gcc's installation cannot remove it.
|
|
rlm@1
|
1398 So you will have to remove it as root before `make install'.
|
|
rlm@1
|
1399 Alternatively use
|
|
rlm@1
|
1400
|
|
rlm@1
|
1401 chown -h gcc: /usr/lib/libgcc*
|
|
rlm@1
|
1402
|
|
rlm@1
|
1403 to change ownership of the files in question after creating the gcc
|
|
rlm@1
|
1404 package user. Note the -h option which has to be used to change
|
|
rlm@1
|
1405 ownership of the symlinks themselves rather than their target files.
|
|
rlm@1
|
1406
|
|
rlm@1
|
1407 db:
|
|
rlm@1
|
1408 It should be obvious that you don't want to change the ownership of the
|
|
rlm@1
|
1409 installed files.
|
|
rlm@1
|
1410
|
|
rlm@1
|
1411
|
|
rlm@1
|
1412 coreutils:
|
|
rlm@1
|
1413 Because the /bin/cat, /bin/pwd and /bin/stty symlinks are owned by root,
|
|
rlm@1
|
1414 coreutils' installation cannot remove them. So you will have to remove
|
|
rlm@1
|
1415 them manually before `make install'. Alternatively use the command
|
|
rlm@1
|
1416
|
|
rlm@1
|
1417 chown -h coreutils: /bin/{cat,pwd,stty}
|
|
rlm@1
|
1418
|
|
rlm@1
|
1419 after creating the coreutils package user. Note the -h switch that makes
|
|
rlm@1
|
1420 chown change the ownership of the symlinks themselves rather than their
|
|
rlm@1
|
1421 target files.
|
|
rlm@1
|
1422
|
|
rlm@1
|
1423 The chapter 6 instructions move the coreutils binaries to /bin, including
|
|
rlm@1
|
1424 the mv binary itself. You need to make sure that hashing is turned off
|
|
rlm@1
|
1425 for this to work. The LFS book does this by putting `set +h' into the
|
|
rlm@1
|
1426 LFS user's .bashrc. If you're following this hint, you're likely using
|
|
rlm@1
|
1427 build scripts, so you need to put this command into the build script
|
|
rlm@1
|
1428 before the mv commands.
|
|
rlm@1
|
1429
|
|
rlm@1
|
1430 NOTE:
|
|
rlm@1
|
1431 The man-pages package has already installed manpages for the binaries
|
|
rlm@1
|
1432 from coreutils. The install wrapper will prevent coreutils from overwriting
|
|
rlm@1
|
1433 those. This is done because the manpages from the man-pages package are
|
|
rlm@1
|
1434 of superior quality (although not necessarily uptodate).
|
|
rlm@1
|
1435 It also prevents errors during `make install' that
|
|
rlm@1
|
1436 would otherwise occur because the coreutils package user cannot overwrite
|
|
rlm@1
|
1437 manpages owned by another user.
|
|
rlm@1
|
1438 If you don't like the above behaviour and would rather have the original
|
|
rlm@1
|
1439 package manpages (because they are uptodate), you can set the variable
|
|
rlm@1
|
1440 manpagesowner at the beginning of the install wrapper to a string that
|
|
rlm@1
|
1441 doesn't correspond to a package user name (it must not be empty, though!).
|
|
rlm@1
|
1442 If you do this, you will have to resolve manpage conflicts in another way.
|
|
rlm@1
|
1443 The easiest way to handle this is probably to not install the man-pages
|
|
rlm@1
|
1444 package at the beginning of Chapter 6 but at the end, after all the other
|
|
rlm@1
|
1445 packages have already installed their manpages. Then you need only deal
|
|
rlm@1
|
1446 with the conflicts once, when installing man-pages.
|
|
rlm@1
|
1447
|
|
rlm@1
|
1448
|
|
rlm@1
|
1449 ncurses:
|
|
rlm@1
|
1450 The installation of ncurses (like that of other packages that include
|
|
rlm@1
|
1451 libraries) wants to run /sbin/ldconfig to update /etc/ld.so.cache.
|
|
rlm@1
|
1452 This fails because the package user doesn't have permission to replace
|
|
rlm@1
|
1453 /etc/ld.so.cache.
|
|
rlm@1
|
1454 Making /etc/ld.so.cache group-writable by the install group doesn't help,
|
|
rlm@1
|
1455 because the permissions would be reset on the next call to /sbin/ldconfig.
|
|
rlm@1
|
1456 This error will usually not abort the installation and you can just
|
|
rlm@1
|
1457 run /sbin/ldconfig manually as root afterwards.
|
|
rlm@1
|
1458 Alternatively you can use the ldconfig wrapper as described earlier.
|
|
rlm@1
|
1459
|
|
rlm@1
|
1460
|
|
rlm@1
|
1461 aclocal directory:
|
|
rlm@1
|
1462 At the time of this writing the directory /usr/share/aclocal is
|
|
rlm@1
|
1463 created during the bison installation. This directory contains
|
|
rlm@1
|
1464 macros for autoconf. Other packages want to install
|
|
rlm@1
|
1465 files into this directory, so you should make it writable by the install
|
|
rlm@1
|
1466 group and sticky.
|
|
rlm@1
|
1467
|
|
rlm@1
|
1468
|
|
rlm@1
|
1469 perl:
|
|
rlm@1
|
1470 Before you do `make install', you will have to
|
|
rlm@1
|
1471 `chown -h perl: /usr/bin/perl' so that the perl package user is allowed to
|
|
rlm@1
|
1472 remove the /usr/bin/perl symlink.
|
|
rlm@1
|
1473
|
|
rlm@1
|
1474 If you will install add-on packages for perl as their own package users
|
|
rlm@1
|
1475 into /usr/lib/perl5/site_perl, then you will need to turn
|
|
rlm@1
|
1476 /usr/lib/perl5/site_perl/ and its subdirectories into
|
|
rlm@1
|
1477 install directories. You don't need to do this now as you'll notice it
|
|
rlm@1
|
1478 anyway when installing a perl add-on fails.
|
|
rlm@1
|
1479
|
|
rlm@1
|
1480
|
|
rlm@1
|
1481 autoconf:
|
|
rlm@1
|
1482 The autoconf package wants to install its own copy of standards.info,
|
|
rlm@1
|
1483 which fails because binutils has already installed this file. You can
|
|
rlm@1
|
1484 either ignore the error or remove the binutils version of standards.info
|
|
rlm@1
|
1485 before `make install'.
|
|
rlm@1
|
1486
|
|
rlm@1
|
1487
|
|
rlm@1
|
1488 bash:
|
|
rlm@1
|
1489 configure:
|
|
rlm@1
|
1490 The bash configure script tests for the presence of the special devices
|
|
rlm@1
|
1491 /dev/std* and /dev/fd/*. Unfortunately at the time of this writing the
|
|
rlm@1
|
1492 test for /dev/fd/* is buggy (the test for /dev/stdin used to be broke, too
|
|
rlm@1
|
1493 in bash-2.x, but has been fixed since). It ends up testing read access to
|
|
rlm@1
|
1494 standard input,
|
|
rlm@1
|
1495 which is the (pseudo)terminal you're building your system in.
|
|
rlm@1
|
1496 Unfortunately su doesn't change ownership of the terminal device, so when
|
|
rlm@1
|
1497 you're su'd to a package user account, the terminal still belongs to the
|
|
rlm@1
|
1498 login user. As the package user doesn't have read access to the device,
|
|
rlm@1
|
1499 the tests fail.
|
|
rlm@1
|
1500
|
|
rlm@1
|
1501 There is a simple way to get around this. Simply run ./configure like this
|
|
rlm@1
|
1502
|
|
rlm@1
|
1503 ./configure .... </dev/null
|
|
rlm@1
|
1504
|
|
rlm@1
|
1505 The trick here is to redirect standard input (note, that this is a '<' not
|
|
rlm@1
|
1506 a '>' !) to refer to /dev/null. Unlike the terminal device, /dev/null is
|
|
rlm@1
|
1507 world-readable and world-writable, so the tests succeed as they should.
|
|
rlm@1
|
1508 If you don't like this trick, you can also chown the terminal device in
|
|
rlm@1
|
1509 question (see `ls -la /dev/fd/0') to the package user before building
|
|
rlm@1
|
1510 bash.
|
|
rlm@1
|
1511
|
|
rlm@1
|
1512 make check:
|
|
rlm@1
|
1513 When running the test suite as a package user, the test "run-test" will
|
|
rlm@1
|
1514 fail with the output like this:
|
|
rlm@1
|
1515
|
|
rlm@1
|
1516 33d32
|
|
rlm@1
|
1517 < *** chmod g+s /tmp/test.setgid
|
|
rlm@1
|
1518 35c34
|
|
rlm@1
|
1519 < 1
|
|
rlm@1
|
1520 ---
|
|
rlm@1
|
1521 > 0
|
|
rlm@1
|
1522 64d62
|
|
rlm@1
|
1523 < *** chmod u+s /tmp/test.setuid
|
|
rlm@1
|
1524 66c64
|
|
rlm@1
|
1525 < 1
|
|
rlm@1
|
1526 ---
|
|
rlm@1
|
1527 > 0
|
|
rlm@1
|
1528 154c152
|
|
rlm@1
|
1529 < 1
|
|
rlm@1
|
1530 ---
|
|
rlm@1
|
1531 > 0
|
|
rlm@1
|
1532 160c158
|
|
rlm@1
|
1533 < 1
|
|
rlm@1
|
1534 ---
|
|
rlm@1
|
1535 > 0
|
|
rlm@1
|
1536
|
|
rlm@1
|
1537 The first 2 failures are caused by the chmod wrapper which prevents the
|
|
rlm@1
|
1538 test from setting the setuid and setgid bits and outputs the *** warning.
|
|
rlm@1
|
1539 The failures are harmless. You can get rid of them by removing the wrappers
|
|
rlm@1
|
1540 directory from the PATH before running the tests.
|
|
rlm@1
|
1541
|
|
rlm@1
|
1542 The last 2 failures are not specific to package users but will occur
|
|
rlm@1
|
1543 whenever you run the tests su'd to another user. The reasons are the same
|
|
rlm@1
|
1544 as for the configure problem described earlier. The same solutions apply.
|
|
rlm@1
|
1545 Either use chown (if you chowned before configure you're already
|
|
rlm@1
|
1546 done, of course) or run make check like this
|
|
rlm@1
|
1547
|
|
rlm@1
|
1548 make check </dev/null
|
|
rlm@1
|
1549
|
|
rlm@1
|
1550 make install:
|
|
rlm@1
|
1551 Before you can `make install' you need to `chown -h bash: /bin/bash' as
|
|
rlm@1
|
1552 root so that the bash installation can replace the /bin/bash symlink that
|
|
rlm@1
|
1553 you manually created at the beginning of chapter 6.
|
|
rlm@1
|
1554
|
|
rlm@1
|
1555
|
|
rlm@1
|
1556 pkgconfig directory:
|
|
rlm@1
|
1557 At the time of this writing the directory /usr/lib/pkgconfig is
|
|
rlm@1
|
1558 created during the e2fsprogs installation. This directory contains
|
|
rlm@1
|
1559 build information used by the pkg-config tool. Other packages want to
|
|
rlm@1
|
1560 install files into this directory, so you should make it writable by the
|
|
rlm@1
|
1561 install group and sticky.
|
|
rlm@1
|
1562
|
|
rlm@1
|
1563
|
|
rlm@1
|
1564 grub:
|
|
rlm@1
|
1565 The commands to create and populate /boot/grub have to be executed as
|
|
rlm@1
|
1566 root.
|
|
rlm@1
|
1567
|
|
rlm@1
|
1568
|
|
rlm@1
|
1569 grep:
|
|
rlm@1
|
1570 Before you can `make install' you need to `chown -h grep: /bin/grep' as
|
|
rlm@1
|
1571 root so that the grep installation can replace the /bin/grep symlink that
|
|
rlm@1
|
1572 you manually created at the beginning of chapter 6.
|
|
rlm@1
|
1573
|
|
rlm@1
|
1574
|
|
rlm@1
|
1575 inetutils:
|
|
rlm@1
|
1576 This package contains some programs that it wants to be setuid root:
|
|
rlm@1
|
1577 rsh, rcp, rlogin and ping
|
|
rlm@1
|
1578 The install wrapper prevents these programs from being installed
|
|
rlm@1
|
1579 setuid root. You must decide which of these programs you want to be
|
|
rlm@1
|
1580 setuid root and manually make them so. Be conservative. Don't make a
|
|
rlm@1
|
1581 binary setuid root unless you *know* that ordinary users can't live
|
|
rlm@1
|
1582 without it. Every setuid root binary is a potential security hole.
|
|
rlm@1
|
1583
|
|
rlm@1
|
1584
|
|
rlm@1
|
1585 iproute2:
|
|
rlm@1
|
1586 This package tries to change the permissions of /usr/sbin and some man
|
|
rlm@1
|
1587 directories. The install wrappers take care of this.
|
|
rlm@1
|
1588
|
|
rlm@1
|
1589
|
|
rlm@1
|
1590 man-db:
|
|
rlm@1
|
1591 Even after installing man-db you won't get manpage summaries from
|
|
rlm@1
|
1592 list_package, because the way list_package calls man it needs col
|
|
rlm@1
|
1593 to work and col is from util-linux. You may however install util-linux
|
|
rlm@1
|
1594 right away. The alphabetical sort is the only reason it is at the end
|
|
rlm@1
|
1595 of Chapter 6.
|
|
rlm@1
|
1596
|
|
rlm@1
|
1597
|
|
rlm@1
|
1598 shadow:
|
|
rlm@1
|
1599 By default shadow wants to install non-English manpages. This fails
|
|
rlm@1
|
1600 because the /usr/share/man directory is not an install directory and
|
|
rlm@1
|
1601 therefore package users are not allowed to create new subdirectories in it.
|
|
rlm@1
|
1602 To solve this problem, before you `make install', open the file
|
|
rlm@1
|
1603 man/Makefile, find the line
|
|
rlm@1
|
1604
|
|
rlm@1
|
1605 SUBDIRS = cs de es fr hu id it ja ko pl pt_BR ru zh_CN zh_TW
|
|
rlm@1
|
1606
|
|
rlm@1
|
1607 and remove all the languages that you don't want to install. For those
|
|
rlm@1
|
1608 languages that you do want to install, create directories with the
|
|
rlm@1
|
1609 respective names in /usr/share/man as root and make them install
|
|
rlm@1
|
1610 directories (i.e. group install, group-writable, sticky).
|
|
rlm@1
|
1611
|
|
rlm@1
|
1612 There is yet another issue with shadow concerning manpages. The shadow
|
|
rlm@1
|
1613 package contains a passwd.5 and a getspnam.3 manpage.
|
|
rlm@1
|
1614 Installation of these manpages is
|
|
rlm@1
|
1615 automatically suppressed by the install wrapper, because it would
|
|
rlm@1
|
1616 overwrite the manpages provided by the man-pages package. As usual
|
|
rlm@1
|
1617 the man-pages version is better, so you can simply ignore this issue.
|
|
rlm@1
|
1618
|
|
rlm@1
|
1619 shadow wants to install the programs su, chage, chfn, chsh, expiry,
|
|
rlm@1
|
1620 gpasswd, newgrp and passwd as setuid root. You will need to decide which
|
|
rlm@1
|
1621 of these programs you want to be setuid root and manually make them so.
|
|
rlm@1
|
1622
|
|
rlm@1
|
1623
|
|
rlm@1
|
1624 sysklogd:
|
|
rlm@1
|
1625 sysklogd's Makefile has /usr/bin/install hardwired as the install
|
|
rlm@1
|
1626 program, which circumvents the install wrapper. The wrapper is needed
|
|
rlm@1
|
1627 for sysklogd because it tries to make its manpages owned by root
|
|
rlm@1
|
1628 (which obviously a package user is not allowed to do).
|
|
rlm@1
|
1629 Therefore, install with
|
|
rlm@1
|
1630
|
|
rlm@1
|
1631 make INSTALL=install install
|
|
rlm@1
|
1632
|
|
rlm@1
|
1633
|
|
rlm@1
|
1634 udev:
|
|
rlm@1
|
1635 udev wants to install files into the directory /usr/lib/pkgconfig. If
|
|
rlm@1
|
1636 you've followed the instructions given further above you've already made
|
|
rlm@1
|
1637 this an install directory. If you haven't, do so now or the udev
|
|
rlm@1
|
1638 installation will fail.
|
|
rlm@1
|
1639
|
|
rlm@1
|
1640 The LFS instructions for installing udev tell you to execute the command
|
|
rlm@1
|
1641
|
|
rlm@1
|
1642 mknod -m0666 /lib/udev/devices/null c 1 3
|
|
rlm@1
|
1643
|
|
rlm@1
|
1644 Because a package user is not allowed to create device nodes, execute this
|
|
rlm@1
|
1645 command as root.
|
|
rlm@1
|
1646
|
|
rlm@1
|
1647
|
|
rlm@1
|
1648 util-linux:
|
|
rlm@1
|
1649 util-linux wants to install write as setgid tty and u/mount as
|
|
rlm@1
|
1650 setuid root. The wrappers catch this, so it doesn't cause the install to
|
|
rlm@1
|
1651 fail, but as usual you'll have to decide if you want these programs to
|
|
rlm@1
|
1652 have special privileges and take manual action as root if you do.
|
|
rlm@1
|
1653
|
|
rlm@1
|
1654
|
|
rlm@1
|
1655 ##########################################################################
|
|
rlm@1
|
1656 8. Sanity Checks
|
|
rlm@1
|
1657 ##########################################################################
|
|
rlm@1
|
1658
|
|
rlm@1
|
1659 8.1 Suspicious Files
|
|
rlm@1
|
1660 --------------------
|
|
rlm@1
|
1661
|
|
rlm@1
|
1662 You probably ran the `list_package' command for each package and reviewed
|
|
rlm@1
|
1663 the results which include the suspicious files owned by that package. But even
|
|
rlm@1
|
1664 if you did that it's still a good idea to run the non-package specific
|
|
rlm@1
|
1665 `list_suspicious_files' command once your build is complete. There could be
|
|
rlm@1
|
1666 something you overlooked the first time, or maybe you created a file as root
|
|
rlm@1
|
1667 with the wrong permissions. It doesn't hurt to check again and this will also
|
|
rlm@1
|
1668 give you the opportunity to review any setuid/setgid decisions you made with
|
|
rlm@1
|
1669 respect to the installed binaries.
|
|
rlm@1
|
1670
|
|
rlm@1
|
1671 TIP:
|
|
rlm@1
|
1672 When you check the list of setuid and setgid files, don't forget to
|
|
rlm@1
|
1673 look at the actual user or group ownership of the file. It's easy to forget
|
|
rlm@1
|
1674 that, especially in the setuid case, because we often equate setuid with
|
|
rlm@1
|
1675 setuid root since setuid is seldom used with other user accounts.
|
|
rlm@1
|
1676
|
|
rlm@1
|
1677
|
|
rlm@1
|
1678 8.2 References to Temporary Files
|
|
rlm@1
|
1679 ---------------------------------
|
|
rlm@1
|
1680
|
|
rlm@1
|
1681 One big concern when building an LFS system is independence of the new LFS
|
|
rlm@1
|
1682 system from the files installed in /tools. The /tools directory is intended
|
|
rlm@1
|
1683 to be temporary and it should be possible to delete it after building your
|
|
rlm@1
|
1684 LFS system with no adverse side effects. The `grep_all_regular_files_for'
|
|
rlm@1
|
1685 script from the more_control_helpers package can help you verify that your
|
|
rlm@1
|
1686 new LFS system is indeed clean. The command
|
|
rlm@1
|
1687
|
|
rlm@1
|
1688 grep_all_regular_files_for /tools
|
|
rlm@1
|
1689
|
|
rlm@1
|
1690 will give you a list of all files that contain the string "/tools". Review the
|
|
rlm@1
|
1691 files in the list to make sure that no dependencies on the temporary files in
|
|
rlm@1
|
1692 /tools have crept in. But remember that results from binaries and libraries
|
|
rlm@1
|
1693 are only meaningful after stripping away the debug information, because
|
|
rlm@1
|
1694 debug information necessarily includes references to the build environment.
|
|
rlm@1
|
1695 Of course, if you are a developer who will potentially run gdb on system
|
|
rlm@1
|
1696 libraries/binaries, your position will be that stripping away debug information
|
|
rlm@1
|
1697 is the wrong way to do away with /tools references. The other way to deal with
|
|
rlm@1
|
1698 them is to rebuild packages for which /tools references are reported. The new
|
|
rlm@1
|
1699 build will not involve any files from /tools and so the new debug information
|
|
rlm@1
|
1700 will not refer to /tools. Note that the LFS build instructions for glibc
|
|
rlm@1
|
1701 make glibc compile against /tools/glibc-kernheaders. Unless you copy the
|
|
rlm@1
|
1702 glibc-kernheaders directory to a location outside of /tools and compile glibc
|
|
rlm@1
|
1703 against that copy, you won't get rid of the /tools references in glibc's
|
|
rlm@1
|
1704 debug information.
|
|
rlm@1
|
1705 No matter what means you choose to deal with the debug information issue, in
|
|
rlm@1
|
1706 the end you should have a system where the above command produces only false
|
|
rlm@1
|
1707 positives (such as "perlfaq3.1", which includes the URL
|
|
rlm@1
|
1708 "http://www.research.att.com/sw/tools/uwin/") and files that legitimately
|
|
rlm@1
|
1709 refer to /tools (such as a copy of this hint file).
|
|
rlm@1
|
1710
|
|
rlm@1
|
1711
|
|
rlm@1
|
1712 ----------------------------- APPENDICES ----------------------------------
|
|
rlm@1
|
1713
|
|
rlm@1
|
1714
|
|
rlm@1
|
1715 ###########################################################################
|
|
rlm@1
|
1716 Appendix A: Security Issues
|
|
rlm@1
|
1717 ###########################################################################
|
|
rlm@1
|
1718
|
|
rlm@1
|
1719 A.1 NFS
|
|
rlm@1
|
1720 -------
|
|
rlm@1
|
1721
|
|
rlm@1
|
1722 If you use the network filesystem NFS, there are some things you need to
|
|
rlm@1
|
1723 look out for when using the package user system. A fundamental security
|
|
rlm@1
|
1724 problem with NFS is that it blindly trusts the UID and GID of the client.
|
|
rlm@1
|
1725 If an attacker can get access to the root account on a system in your network
|
|
rlm@1
|
1726 that is allowed to mount NFS shares from your server, or if the attacker can
|
|
rlm@1
|
1727 attach his own computer to your network, then this attacker can pretend to be
|
|
rlm@1
|
1728 anyone. NFS will happily allow the attacker to work in the NFS exported
|
|
rlm@1
|
1729 directory as any user he wants to be. The only exception is the root account.
|
|
rlm@1
|
1730 By default NFS exports directories with the root_squash option that maps all
|
|
rlm@1
|
1731 incoming requests from uid 0 to anonuid (65534 unless set in /etc/exports)
|
|
rlm@1
|
1732 and gid 0 to anongid (65534 unless set in /etc/exports). This protects files
|
|
rlm@1
|
1733 owned by root:root. On a normal system this includes most files in /bin, /etc,
|
|
rlm@1
|
1734 /lib and most other directories except /home. If you use the package user
|
|
rlm@1
|
1735 scheme, however, most of these files are owned by package users. These files
|
|
rlm@1
|
1736 are not protected by the root_squash option. In order to make NFS exports
|
|
rlm@1
|
1737 secure, you have to add the option "all_squash" to every entry in /etc/exports
|
|
rlm@1
|
1738 that exports a directory that contains files owned by package users. Note that
|
|
rlm@1
|
1739 all_squash is always a good idea because even systems that don't use package
|
|
rlm@1
|
1740 users often have some programs owned by other users or groups, because they
|
|
rlm@1
|
1741 need to be setuid or setgid.
|
|
rlm@1
|
1742
|
|
rlm@1
|
1743
|
|
rlm@1
|
1744 A.2 Daemons
|
|
rlm@1
|
1745 -----------
|
|
rlm@1
|
1746
|
|
rlm@1
|
1747 It is a common practice to run daemons under special user accounts rather
|
|
rlm@1
|
1748 than as root as a security measure. If you feel tempted to use a package
|
|
rlm@1
|
1749 user account for this purpose, resist the temptation. It would be a very
|
|
rlm@1
|
1750 stupid idea. Although they are deliberately less powerful than root, package
|
|
rlm@1
|
1751 user accounts are still privileged and need to be considered as equivalent to
|
|
rlm@1
|
1752 root as far as security is concerned. Do not do anything with a package user
|
|
rlm@1
|
1753 that on a system without package users you would not do with the root account.
|
|
rlm@1
|
1754
|
|
rlm@1
|
1755
|
|
rlm@1
|
1756 ###########################################################################
|
|
rlm@1
|
1757 Appendix B: Package Categories
|
|
rlm@1
|
1758 ###########################################################################
|
|
rlm@1
|
1759
|
|
rlm@1
|
1760 Although the user name = group name scheme is recommended by this hint, it is
|
|
rlm@1
|
1761 not the only possible one. Another scheme that has some appeal is to define
|
|
rlm@1
|
1762 package categories and to use the group for the purpose of categorizing the
|
|
rlm@1
|
1763 packages. Following is a suggested set of categories that can serve as a
|
|
rlm@1
|
1764 guideline for implementing this scheme.
|
|
rlm@1
|
1765
|
|
rlm@1
|
1766 devel: development related stuff, e.g. compilers. This is not restricted to
|
|
rlm@1
|
1767 software development. TeX for instance would belong in this group.
|
|
rlm@1
|
1768
|
|
rlm@1
|
1769 utils: Most software fits into this category, even somewhat essential software
|
|
rlm@1
|
1770 like grep or text editors.
|
|
rlm@1
|
1771
|
|
rlm@1
|
1772 net: network related stuff such as an ftp daemon or a web browser. This
|
|
rlm@1
|
1773 group overlaps with other groups to a large extent. It should be used
|
|
rlm@1
|
1774 in preference of the other groups whenever a package is clearly focused
|
|
rlm@1
|
1775 towards Internet, LAN, WWW,... A utility like wget for instance would
|
|
rlm@1
|
1776 go in net rather than utils. Exceptions from this rule are the groups
|
|
rlm@1
|
1777 docs, addons, games and mmedia. If a package fits into one of those
|
|
rlm@1
|
1778 groups, use the respective group instead of net.
|
|
rlm@1
|
1779
|
|
rlm@1
|
1780 docs: Documentation related packages, such as a tarball with Linux howtos.
|
|
rlm@1
|
1781 Note that software to create documentation such as XML processors should
|
|
rlm@1
|
1782 probably go in devel and software to view or post-process documentation
|
|
rlm@1
|
1783 such as man or groff should probably go in utils.
|
|
rlm@1
|
1784
|
|
rlm@1
|
1785 system: important system software, such as bash. This group should be used
|
|
rlm@1
|
1786 only for really essential packages. Most packages you would put in
|
|
rlm@1
|
1787 this group are better put in "utils". Vi for instance belongs in
|
|
rlm@1
|
1788 utils.
|
|
rlm@1
|
1789 It is unlikely that any package not part of basic LFS belongs in the
|
|
rlm@1
|
1790 system group.
|
|
rlm@1
|
1791
|
|
rlm@1
|
1792 libs: What utils is for executables, libs is for libraries. Libraries that are
|
|
rlm@1
|
1793 not strongly related to any of the other categories should go here, such
|
|
rlm@1
|
1794 as zlib or libpng.
|
|
rlm@1
|
1795 Essential system libraries such as glibc, ncurses or gettext should
|
|
rlm@1
|
1796 go in system instead.
|
|
rlm@1
|
1797 The libs group is also used for run-time environments such as the
|
|
rlm@1
|
1798 Java Virtual Machine, dosemu and wine. Other emulators like MAME for
|
|
rlm@1
|
1799 instance should probably go into games instead.
|
|
rlm@1
|
1800
|
|
rlm@1
|
1801 games: what do you expect ;-)
|
|
rlm@1
|
1802
|
|
rlm@1
|
1803 mmedia: This is the group for audio and video editors, mp3 players etc.
|
|
rlm@1
|
1804
|
|
rlm@1
|
1805 apps: Applications such as spreadsheets and word processors (not text editors)
|
|
rlm@1
|
1806 but also CAD software and graphics software such as Gimp.
|
|
rlm@1
|
1807 The apps group is a bit like utils, but apps are usually more user
|
|
rlm@1
|
1808 friendly and more streamlined and feel less nerdish than utils.
|
|
rlm@1
|
1809
|
|
rlm@1
|
1810 addons: plugins, filters and similar that are meant to be used in conjunction
|
|
rlm@1
|
1811 with another package.
|
|
rlm@1
|
1812
|
|
rlm@1
|
1813 x: software that relates to the X Window System in general and does not fit
|
|
rlm@1
|
1814 into any of the other categories, such as the X server itself or window
|
|
rlm@1
|
1815 managers.
|
|
rlm@1
|
1816 Most X software should be put into other more specific groups.
|
|
rlm@1
|
1817 A game like xmines would go in games for instance and a text editor for
|
|
rlm@1
|
1818 X would go in utils.
|
|
rlm@1
|
1819
|
|
rlm@1
|
1820 kde: Software that relates to KDE and does not fit into
|
|
rlm@1
|
1821 any other category. This group should be used with care.
|
|
rlm@1
|
1822 Do *not* use it for all KDE software. K Office for instance belongs in
|
|
rlm@1
|
1823 apps. Konqueror belongs in net.
|
|
rlm@1
|
1824
|
|
rlm@1
|
1825 gnome: Software that relates to GNOME and does not fit into
|
|
rlm@1
|
1826 any other category. This group should be used with care.
|
|
rlm@1
|
1827 Do *not* use it for all GNOME software. Gimp for instance belongs
|
|
rlm@1
|
1828 in apps. A GNOME-aware window manager that works with plain X should
|
|
rlm@1
|
1829 go in the x group.
|
|
rlm@1
|
1830
|
|
rlm@1
|
1831
|
|
rlm@1
|
1832 ###########################################################################
|
|
rlm@1
|
1833 Appendix C: Acknowledgements and Changelog
|
|
rlm@1
|
1834 ###########################################################################
|
|
rlm@1
|
1835
|
|
rlm@1
|
1836 ACKNOWLEDGEMENTS:
|
|
rlm@1
|
1837 * Matthias Benkmann for writing the original version of this hint
|
|
rlm@1
|
1838 * Tushar Teredesai for suggesting the user=group scheme.
|
|
rlm@1
|
1839 * Markus Laire for reporting the 2005-01-01 build bug
|
|
rlm@1
|
1840
|
|
rlm@1
|
1841 CHANGELOG:
|
|
rlm@1
|
1842
|
|
rlm@1
|
1843 2007-10-20 Matthias Benkmann
|
|
rlm@1
|
1844 -relicensed under CC-BY-SA (previously CC-BY-ND).
|
|
rlm@1
|
1845 -added name tags to changelog entries in preparation for having the
|
|
rlm@1
|
1846 hint continued by different authors.
|
|
rlm@1
|
1847 -added workaround to list_package for bug in man-db that causes
|
|
rlm@1
|
1848 some manpages to show up as "Weird manpage" in the summary.
|
|
rlm@1
|
1849 -chmod wrapper now prevents shadow from installing files setuid
|
|
rlm@1
|
1850 shadow.
|
|
rlm@1
|
1851 -added a wrapper to solve ldconfig issue.
|
|
rlm@1
|
1852 -install_package now works when called with just a single argument.
|
|
rlm@1
|
1853 That argument is used for user name, group name and description.
|
|
rlm@1
|
1854 -bash_profile of more_control_helpers now has /sbin and /usr/sbin
|
|
rlm@1
|
1855 in the PATH to match the PATH used by root when building.
|
|
rlm@1
|
1856 -install_package does su - <name> now (i.e. start a login shell).
|
|
rlm@1
|
1857 -build script now handles unpacking of tarballs and allows calling
|
|
rlm@1
|
1858 the different stages individually.
|
|
rlm@1
|
1859 -useradd uses the -s provided shell and no longer hardwires bash.
|
|
rlm@1
|
1860 -chapter 6 bash notes now properly address the configure and
|
|
rlm@1
|
1861 make check issues.
|
|
rlm@1
|
1862
|
|
rlm@1
|
1863 2007-03-21 Matthias Benkmann
|
|
rlm@1
|
1864 -changed forall_direntries_from to avoid warning message from find
|
|
rlm@1
|
1865 when -depth is used.
|
|
rlm@1
|
1866 -added 4.8 What Commands to Run as a Package User
|
|
rlm@1
|
1867
|
|
rlm@1
|
1868 2005-12-22 Matthias Benkmann
|
|
rlm@1
|
1869 -added advice on how to cope with the moving mv problem to
|
|
rlm@1
|
1870 coreutils note.
|
|
rlm@1
|
1871
|
|
rlm@1
|
1872 2005-11-13 Matthias Benkmann
|
|
rlm@1
|
1873 -fixed list_suspicious_files and list_package to work with
|
|
rlm@1
|
1874 recent more POSIX-conforming versions of GNU find
|
|
rlm@1
|
1875 -released version 1.2
|
|
rlm@1
|
1876
|
|
rlm@1
|
1877 2005-01-01 Matthias Benkmann
|
|
rlm@1
|
1878 -fixed bug in skel-package/build script that caused it to report
|
|
rlm@1
|
1879 all steps as successful, even if they failed
|
|
rlm@1
|
1880 -released version 1.1
|
|
rlm@1
|
1881
|
|
rlm@1
|
1882 2004-11-01 Matthias Benkmann
|
|
rlm@1
|
1883 -capitalized title
|
|
rlm@1
|
1884 -released version 1.0
|
|
rlm@1
|
1885
|
|
rlm@1
|
1886 2004-10-14 Matthias Benkmann
|
|
rlm@1
|
1887 -started developing the more_control_helpers utilities
|
|
rlm@1
|
1888
|
|
rlm@1
|
1889 2004-08-14 Matthias Benkmann
|
|
rlm@1
|
1890 -started major rewrite (update for new LFS version, new hint
|
|
rlm@1
|
1891 format, textual improvements,...)
|
|
rlm@1
|
1892
|
|
rlm@1
|
1893 2002-04-20 Matthias Benkmann
|
|
rlm@1
|
1894 -changed LFS VERSION header to be more conservative
|
|
rlm@1
|
1895 -added <br> tags to the synopsis for the sake of the hints
|
|
rlm@1
|
1896 index
|
|
rlm@1
|
1897 -added group mmedia to the list of suggested groups
|
|
rlm@1
|
1898 -submitted v0.8
|
|
rlm@1
|
1899
|
|
rlm@1
|
1900 2002-03-16 Matthias Benkmann
|
|
rlm@1
|
1901 -added note, that on Linux make doesn't need to be setgid kmem
|
|
rlm@1
|
1902
|
|
rlm@1
|
1903 2002-02-18 Matthias Benkmann
|
|
rlm@1
|
1904 -added section "Security issues with NFS"
|
|
rlm@1
|
1905 -submitted v0.7
|
|
rlm@1
|
1906
|
|
rlm@1
|
1907 2002-01-30 Matthias Benkmann
|
|
rlm@1
|
1908 -added Changelog
|
|
rlm@1
|
1909 -moved "chown 0.10000 `cat /tmp/installdirs`" command up (before
|
|
rlm@1
|
1910 glibc package user is created)
|
|
rlm@1
|
1911 -add_package_user: create home directory with "mkdir -p"
|
|
rlm@1
|
1912 use $grpfile everywhere instead of /etc/group
|
|
rlm@1
|
1913 -improved mammoth sentence in Introduction
|
|
rlm@1
|
1914 -added note about possibility to have user name==group name
|
|
rlm@1
|
1915 -source bashrc_basic in bashrc_package
|
|
rlm@1
|
1916 -minor textual changes
|
