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