1 AUTHOR: Matthias S. Benkmann <article at winterdrache dot de>
5 LICENSE: Creative Commons Attribution-NoDerivs 2.0
6 (http://creativecommons.org/licenses/by-nd/2.0/)
8 SYNOPSIS: More Control and Package Management using Package Users (v1.2)
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 ?
19 http://www.linuxfromscratch.org/hints/downloads/attachments/more_control_and_pkg_man/more_control_helpers.tar.bz2
22 For use with LFS book 6.0: Brain.
23 For use with LFS book later than 6.0: Brain (awake, good working condition).
27 ###########################################################################
29 ###########################################################################
34 - PART 1: General Information -
44 4.3 Permission Changes
46 4.5 Write to Non-Install Directory
47 4.6 Delete or Overwrite File
49 5. The more_control_helpers Archive
52 5.3 add_package_user/install_package
53 5.4 forall_direntries_from
55 5.6 list_suspicious_files/list_suspicious_files_from
57 5.8 grep_all_regular_files_for
61 - PART 2: LFS Specifics -
63 6. Pre-Chroot Phase (Chapter 5)
64 7. Chroot Phase (Chapter 6)
66 7.2 Walkthrough: Installing linux-libc-headers
67 7.3 Known Issues with LFS Packages
70 8.2 References to Temporary Files
78 C. Acknowledgements and Changelog
81 ###########################################################################
83 ###########################################################################
85 Let's say I have written a program that you would like to use. To make it
86 easier for you I come over to install it for you. Would you give me the root
87 account and then leave the room ? No ? Then why do you give it to complete
88 strangers who you have never seen in your life, to install software packages
89 pulled from some Internet server, that come with no warranty and don't even
90 list their contents in the README, although they will happily spread them all
93 It is a mystery why Unix admins who wouldn't even trust their employer with
94 more than a normal user account carelessly execute complex and incomprehensible
95 installation scripts with full root rights.
97 Users and groups are the basic security principle in a Unix system. They have
98 been used successfully for a long time to monitor who has created a file and
99 to control who is allowed to delete or change it. But this control has only
100 been imposed on the files of ordinary users. What a waste! I suggest to extend
101 this control to all system files.
103 The general idea is to create package users, i.e. user accounts with restricted
104 rights, to build and install software packages, rather than doing these tasks
105 as root. Not only does this give you more control over what build and install
106 scripts may or may not do, it can also serve as a quite useful package
110 #############################################################################
112 #############################################################################
114 This hint is divided into 3 parts. The first part contains general information
115 about the package user method. This part is the most important part of the
116 hint. Read it thoroughly. The second part explains how to apply the package
117 user method to the building of an LFS system.
118 Finally, part 3 of this hint is the Appendix with information that would not
119 fit anywhere else or that is not of general interest.
121 It is inevitable that part 2 will become outdated with time as the LFS book
122 changes and new versions of the software packages used with LFS are released.
123 I make no attempt to track these changes.
124 When someone reports an issue with a package I will incorporate
125 it into the hint, but larger changes that might be required due to changes in
126 the LFS build methodology could take a long time to get included. The reason
127 for this (aside from lack of time) is that I consider part 2 as bonus material
128 that helps people get started but is not essential. Part 1 describes the
129 concepts, which are independent of package versions or the LFS book, and you
130 will have to rely on this information whenever part 2 fails. Don't forget
131 that part 2 only deals with the packages used by the LFS book. For all the
132 other packages you install on your system after that even an up-to-date
133 part 2 would offer no aid anyway.
135 The previous paragraph might sound discouraging, and as you read more from the
136 hint it is possible that you get the impression that the package user
137 method is complicated, causes lots of difficult problems and is overall too
138 much trouble for anyone but a real hardcore admin with programming experience.
139 But you would be mistaken.
140 First of all, many things experienced as installation problems when working
141 with the package user system are in fact desirable features.
142 If `make install' fails for some package, because it attempts to install a
143 file with the same name as a pre-existing file from another package, you
144 should not curse the fact that you have to spend additional time to resolve
145 this issue. Instead you should be happy that you have been alerted of this
146 collision that, had it gone unnoticed, could have messed up your system in
147 more or less subtle ways.
148 Secondly, the package user system is not an all-or-nothing approach. It
149 works on a per-package basis. If a package gives you too much trouble, you
150 can always decide to chicken out and finish the installation as root.
151 Finally, the more_control_helpers archive provided with this hint contains
152 several useful scripts that automate many aspects of software installation
153 as a package user and, together with the tips given in this hint, add a lot
154 of value to the package user system.
155 So do not pass judgement until you have read at least the complete part 1,
156 including the description of the more_control_helpers.
159 ---------------------- PART 1: General Information --------------------------
162 #############################################################################
164 #############################################################################
169 The basic idea of this scheme is easily explained. Every package belongs to a
170 certain "package user". When you install a package, you build and install
171 the package as this package user, causing all files that are installed to be
172 owned by the package user. As a consequence all the usual package management
173 tasks can be comfortably achieved through the use of standard command line
174 utilities. A simple `ls -l <file>' will tell you, for instance, what package
175 <file> belongs to and a `find -user ...' command allows you to perform an
176 operation on all the files belonging to a certain package, e.g. delete them
177 to uninstall the package.
179 But package management is not all that package users are good for. Because
180 package users do not have root-rights, the installation of a package is
181 limited in what it can do. One thing that a package user is not allowed to do,
182 for example, is to overwrite files from a different package user. Clashes
183 between different packages that want to install a binary, library or header
184 file of the same name are more common than you might think. With package users
185 you never run the risk of package B's installation destroying files from
186 package A silently without you noticing. Every attempt of doing this during
187 package B's installation will cause a "Permission denied" or
188 "Operation not permitted" error so that you have the chance of taking
190 Another thing that package users are not allowed to do is install setuid root
191 binaries. The decision to make a binary setuid root is also something that a
192 prudent admin does not want to leave up to the creator of a software package.
194 Usually package user accounts have no valid password so that only root can su
195 to a package user, which ensures that package users do not open an additional
196 way into the system and undermine security. But you *may* set passwords
197 anyway to allow a co-admin who you want to be able to install and maintain
198 certain software packages to do so without having access to the actual root
199 account. This co-admin could for instance install, delete, change additional
200 libraries which might be necessary for his workgroup. He would be unable,
201 though, to remove or modify libraries which don't belong to him/her, such as
208 You don't need to drive yourself nuts trying to come up with 8 character
209 names for the package users. I always use the name of the package without
210 the version number, including dashes and possibly exceeding 8 characters in
211 length, e.g. "util-linux", and in the several years that I've been using this
212 scheme I have not encountered any problems, nor has anyone else reported
213 trouble. The 8-character limit on user names seems to be a thing of the past.
216 You can use bash's programmable completion feature to save yourself some
217 typing when entering commands that take a user name as an argument, such as
218 su, finger or pinky. The command
220 complete -o default -o nospace -A user su finger pinky
222 tells bash to tab-complete words as user names for the commands su,
224 With this in place you can simply type `su linux-li<TAB>' and bash
225 will complete this to `su linux-libc-headers' (assuming that you have a
226 package user named "linux-libc-headers").
227 "-o default" tells bash that if a suitable user name does not exist, the
228 default completion shall be attempted.
229 "-o nospace" prevents the addition of a space after the completed word.
231 This is a very useful command to put into root's .bashrc and .bash_profile.
233 BTW, at http://freshmeat.net/projects/bashcompletion/
234 you can find a project that offers sophisticated completions for many
241 Every package user belongs to at least 2 groups. One of these groups is
242 the "install" group, which all package users (and only package users) belong
243 to. All directories that packages are allowed to install stuff in belong to
244 the install group. This includes directories such as /bin and /usr/bin but
245 excludes directories like /root or /.
246 The directories owned by the install group are always group-writable.
247 This would be enough for the package management aspects, but without further
248 preparation this would not give added security or control because every
249 package could replace the files from a different package (the change would
250 be visible in the output from `ls -l', though).
251 For this reason all install directories get the sticky attribute. This
252 allows users to create new files and delete or modify their own files in
253 the directory, but files from other users can not be modified or removed.
254 In the rest of this hint, whenever the term "install directory" is used, it
255 refers to a directory that belongs to group install, is group-writable and
256 sticky. IOW, to turn <dir> into an install directory you would do
258 chgrp install <dir> && chmod g+w,o+t <dir>
260 Although the install group is crucial for the package user system, it is
261 implemented as a supplementary group, rather than as the primary group for
262 package users. This has at least 2 advantages.
263 One advantage is that this makes it easy to get a list of all packages
264 installed on the system with the command
266 grep install /etc/group
268 A more important point, however, is that the primary group is the
269 one that files created by the package user will belong to. So it will be
270 printed in the output of `ls -l' and is subject to find's "-group" test.
271 This makes it very useful for organizational purposes.
272 Following are some suggestions for how to use the primary group.
274 1. group name = user name
276 Under this scheme the package user for the bash package would be
277 bash:bash. `ls -l /bin/bash' would show something like this
279 -rwxr-xr-x 1 bash bash 1731859 Feb 30 2005 /bin/bash
281 An important advantage of this scheme is that the user information is
282 not lost when you make a file setuid root, which requires changing
283 the file's owner. Because of this advantage, this scheme is the one
284 recommended by this hint. However, the hint's instructions will work
285 fine if you choose a different scheme.
287 2. group name = package category
289 Under this scheme, you would have certain package categories, such as
290 games, system, net,... and bash, being a system program, would possibly
291 belong to the system group, so that `ls -l /bin/bash' would show something
294 -rwxr-xr-x 1 bash system 1731859 Jul 4 1776 /bin/bash
296 This system is nice, but probably not as useful as #1 above, unless you
297 have a real use for this categorization.
298 For a possible categorization see Appendix B at the end of this hint.
300 3. group name = identifier for a real group of people
302 Under this scheme, the group would correspond to a real group of people in
303 meatspace, e.g. the group of admins responsible for the package.
304 If you need something like this you'll know best what it looks like and how
305 to implement it, so no further discussion of this method will be given here.
311 Although it is well possible not to have a valid home directory for package
312 users or to have just one home directory shared by all package users, that
313 would be a wasted opportunity. Having individual home directories for the
314 package users offers a nice way to organize tarballs, patches, build scripts,
315 notes and all the other per-package information that you accumulate with time.
317 I suggest to use the home directory /usr/src/<package> for a package user
318 called <package> with the contents detailed below. The more_control_helpers
319 archive contains scripts and skeleton files that implement this suggestion.
322 You will usually want to have the same environment for all package
323 users, so it is a good idea to make .bash_profile a symbolic link
324 to a file in a central location. The more_control_helpers example
325 uses /etc/pkgusr/bash_profile for this purpose.
328 As for .bash_profile a symlink is a good idea for .bashrc. The
329 more_control_helpers example uses /etc/pkgusr/bashrc as link target.
330 Under normal circumstances package users are not
331 (and even can not be) used for logging into the system, so there
332 is little reason to distinguish between login and non-login shells
333 for package users. Therefore, the example bashrc from
334 more_control_helpers simply sources .bash_profile.
335 This makes sure that the same environment will be used, regardless
336 of whether `su <package>' or `su - <package>' is used to become
340 The contents of this file are printed by the commands
341 `finger -l <user>' and 'pinky -l <user>' so .project is a
342 good place for putting information about a package. You should
343 keep the contents of the .project files for your package users
347 The package user's home directory is the perfect place for storing
348 a package's source code. This includes tarballs for different
349 versions, CVS checkouts, unpacked source trees for building,...
352 Package user installations require more careful examination of build
353 and install messages than installations done as root, because of
354 the package user-specific problems that can occur. Therefore it is
355 unwise to simply copy'n'paste installation instructions from the
356 LFS book. Build scripts allow you to use sophisticated output
357 redirection for logging purposes that is impractical for direct
358 entry on the command line. The build script skeleton included in
359 the more_control_helpers archive demonstrates this.
362 ############################################################################
364 ############################################################################
369 Software installation is the crux of the package user system. Because
370 installation scripts are often written under the assumption that they will be
371 executed as root, they sometimes fail when executed by a package user.
372 Once this hurdle is passed and a package has been installed, there's usually no
373 difference to a root-installation. A few programs insist that certain
374 security-sensitive files be owned by root and will not execute otherwise,
375 but this is the rare exception.
376 This chapter presents some more or less common problems that you will
377 encounter when using package user accounts to install software, together with
378 guidelines on how to deal with these issues.
379 Although I've said it before I will say it again: Many of the problems you
380 encounter during a package user installation are desirable features of the
381 package user system. You want installation to fail rather than have
382 potentially dangerous actions performed behind your back with root rights.
385 4.2 General Procedure
386 ---------------------
388 When an installation fails it is almost always due to a "Permission denied"
389 or "Operation not permitted" error while executing a command during
390 `make install'. The first thing you have to do is identify the command that
391 is causing the problem. Usually you will find this in the make output right
392 before the error message. Once you have identified the culprit, you have to
393 decide whether the action that is attempted is illegitimate, partially
394 legitimate or completely legitimate. Illegitimate commands can simply be
395 removed from the Makefile. The other 2 possibilities are more difficult to
396 deal with. You either have to change the condition that makes the command fail
397 or you have to change or sometimes remove the command and make a note if your
398 change suppresses a legitimate action.
400 After you've made changes to solve a certain problem, you reattempt the
401 installation and solve any remaining problems until the installation
402 succeeds. Once you've reached that point it is time to perform any remaining
403 legitimate actions that you've had to disable, such as make certain binaries
406 Note that often Makefiles are generated during the configure step, sometimes
407 even later in the build process. If you want to apply changes before the
408 configure step you will usually have to edit files called "Makefile.in".
411 4.3 Permission Changes
412 ----------------------
414 Some unsophisticated build systems that don't use the mkinstalldirs script to
415 create installation target directories are very poorly written. Instead of
416 testing whether a target directory exists, they simply attempt to create
417 it with default permissions. This problem usually manifests as a line such
418 as "install -d $(prefix)/bin" in the Makefile. In the common case where
419 prefix=/usr this would attempt to create the /usr/bin directory. If the target
420 directory already exists, as in this case, install will attempt to change its
421 permissions to the default permissions (or those passed on the command line).
422 Of course a package user is not allowed to change the permissions of
423 /usr/bin and so the command fails with a message like
424 "install: cannot change permissions of `/usr/bin': Operation not permitted"
425 This is an example of a completely illegitimate command. Just remove it from
426 the Makefile and everything's fine.
429 4.4 Ownership Changes
430 ---------------------
432 The most common situation when a package wants to change the ownership of
433 files during installation is when it wants to install setuid root binaries.
434 A common command to do this would be something like
435 "install -c -m 4755 -o root name /usr/bin/name" and the error message would
437 "install: cannot change ownership of `name': Operation not permitted"
438 The change of ownership is hidden in the "-o root" switch to install, which
439 tells it to make the target file owned by root.
440 The command is at least partially legitimate, because you probably want the
441 binary to be installed. Whether you actually want it to be setuid root is
442 a different matter. The fact that a binary is commonly installed as setuid
443 root doesn't mean that you should make it so. You'll have to ask yourself if
444 normal users absolutely need to execute that binary. If you think they can
445 live without it you're better off not making it setuid root, because every
446 setuid root binary is a potential security hole. In any case you will
447 have to edit the Makefile and remove the offending switch, "-o root" in this
448 case, so that the installation can succeed. Note that this will cause the
449 binary to be installed setuid <package>, which of course makes no sense at all.
450 If you don't intend to make the binary setuid root after the installation, it
451 is best to change the "-m 4755" to "-m 755", so that it won't be installed
455 When you make a binary setuid root after the installation, use
456 `chown root /usr/bin/name' and not `chown root:root /usr/bin/name'.
457 This way you can keep original group of the file (i.e. the group of the
458 package user) intact. With the user name = group name scheme recommended for
459 package users this makes sure that you can identify the source package of
460 the binary even after making it setuid root.
461 Note that as a security measure chown resets the setuid bit,
462 so you will have to do `chmod u+s /usr/bin/name' after the chown.
465 4.5 Write to Non-Install Directory
466 ----------------------------------
468 Sometimes packages want to create files or directories in non-install
469 directories. 3 situations have to be distinguished in this case. The 1st
470 possibility is that the target directory should be an install directory.
471 An example of this is /usr/share/aclocal. This directory is not among the
472 standard system directories created when building an LFS system. It will be
473 created by the first package that has files to install there and will be
474 owned by the corresponding package user. The next package that wants to write
475 in it will fail to install. The remedy is simple. Just make the directory an
476 install directory. You don't even need to be root to do it. The package user
477 that owns the directory has the rights to make that change.
479 The 2nd possible reason for a package wanting to write to a non-install
480 directory is that the failing command is only partially legitimate, i.e. you
481 do want to have installed whatever it is meant to install, but you want it in
482 a different location. For example some packages install binaries that are not
483 meant to be called directly. The default location for these binaries is
484 sometimes called libexec and with prefix=/usr the package will attempt to
485 create /usr/libexec. In cases such as this you often don't have to change
486 any Makefiles. There is either a configure switch to change the directory in
487 question or it is just a matter of overriding a Makefile variable as in
488 `make libexecdir=/usr/lib install'.
490 The 3rd possible reason for an attempt to write to a non-install directory is
491 that the command in question is illegitimate, i.e. you don't want to have
492 installed whatever the package wants to install. As usual with illegitimate
493 commands you can edit the Makefile and just remove them. In the case of
494 a whole directory whose installation you want to suppress it could be too
495 much effort to remove all of the offending commands that want to install
496 files there. In this case an approach similar to that from the previous
497 paragraph can be more effective. Either through configure switches or
498 overriding of variables you change the directory in question to something
499 like <builddir>/foobar, where <builddir> is the directory in which build
500 commands are run (i.e. usually the top of the unpackaged source
501 tree). This will cause the package to create the unwanted directory inside
502 the build tree, which doesn't cause any permission problems and has the nice
503 side effect that it'll be deleted together with the build directory when you
504 clean up after the build.
507 4.6 Delete or Overwrite File
508 ----------------------------
510 In a perfect world one package should not mess with another package's files,
511 but in the real world conflicts do happen occasionally. While a normal
512 sysadmin installing as root won't notice this until it's too late, an admin
513 employing the package user system will have to deal with conflicts right away.
514 When a package tries to overwrite or delete a file or directory that is owned
515 by another package the attempt will fail. It will fail even inside install
516 directories because of the sticky bit.
517 Although sometimes difficult to implement, the solution to such a conflict is
518 easy to describe. You need to either remove (or rename) the old file or
519 directory before installing, or suppress the installation of the new file or
520 directory. The installation of individual binaries is sometimes easy to
521 prevent. If you find a line such as "PROGRAMS=foo bar fubar barfu" in the
522 Makefile and "foo" is the name of the conflicting binary, just try removing
523 it from that list. That may be sufficient to prevent it from being installed.
529 Packages that install libraries sometimes run /sbin/ldconfig as part of their
530 installation so that the dynamic libraries are properly registered on the
531 system. Because a package user is not allowed to overwrite /etc/ld.so.cache
532 ldconfig fails. This failure is commonly ignored in Makefiles, but you should
533 take note of it anyway, because you need to run ldconfig as root after
537 ############################################################################
538 5. The more_control_helpers Archive
539 ############################################################################
544 The more_control_helpers archive contains files to help you with building and
545 maintaining a system that uses the package user method. One thing that the
546 more_control_helpers archive contains are some LFS-specific temporary files
547 that are only needed for the building of your LFS system and will not remain
548 installed in a permanent location. Then there are the previously mentioned
549 example files that demonstrate the suggested use of the package user home
550 directories discussed earlier. Another group of files contained in the archive
551 is a set of scripts that help with package management aspects, such as
552 creating new package users and checking which files a particular package has
553 installed. Finally the more_control_helpers archive contains wrapper scripts
554 for some commands that handle many of the common problems discussed in the
555 previous chapter and make package user installations a lot easier.
561 The previous chapter discussed some common problems encountered during
562 package user builds and how to solve them. The solution to an installation
563 failure usually requires editing of one or more Makefiles. Making such changes
564 manually is annoying, even if it happens only occasionally, and whenever you
565 reinstall a package you have to make the changes again. Sed scripts and patches
566 can help with the latter problem, but they still have to be custom fitted to
567 every package that needs them. There is a better solution, though. While there
568 exist countless ways to install files, only very few are commonly used by
569 packages. The 5 commands mkdir, chgrp, chown, chmod and install are responsible
570 for many of the common problems that arise during an LFS installation. This
571 prompted me to write wrapper scripts for these 5 commands that recognize
572 certain problematic patterns and deal with them automatically.
574 The instructions given in this hint in the LFS-specific part will instruct you
575 to install these wrappers in /usr/lib/pkgusr. If you do that and make sure
576 that this directory is the first entry in the PATH of every package user, then
577 they will save you a lot of time and effort in dealing with recurring issues.
578 Note that if you want to choose a directory other than /usr/lib/pkgusr for
579 the wrappers, you need to be careful. Some configure scripts ignore certain
580 locations. A subdirectory of /etc would not work, for instance, because /etc
581 is one of these locations.
583 It is important that you understand the limitations of the wrapper scripts.
584 They can fix some problems without user intervention, such as turning
585 newly created directories in /usr/share/locale into install directories.
586 But other problems by their very nature require manual intervention. When a
587 program tries to install a setuid root binary, for instance, the wrapper
588 scripts will suppress the attempt to change ownership of an installed file to
589 root. While that allows `make install' to complete without error, it is only
590 a partial solution. The wrapper scripts can not (and should not) take away
591 your responsibility for deciding whether the program in question should be
592 setuid root and to make it so, if necessary. To account for this, the
593 wrapper scripts will output warning lines to standard error that start with
594 "***" whenever they encounter a situation that needs to be reviewed.
595 Following the "***" in the message will be the original command that the
596 installation attempted to perform.
597 You *must* check these "***" lines, examine the affected files or directories
598 and take appropriate action. Because of this it is imperative that you log
599 the messages output during a package installation and check these logs
600 religiously. The `build' script contained in the more_control_helpers archive
601 demonstrates some useful output redirection tricks to be used for this purpose.
602 The following 3 examples shall illustrate what kind of things you will have to
605 Example 1: "*** install -c rsh -o root -m 4775 /usr/bin/rsh"
606 This message is output by the install wrapper during the installation of
607 inetutils. The package wants to install the rsh binary setuid root. The
608 install wrapper removes the "-o root" and changes the "-m 4775" to
609 "-m 755" before passing the command on to the real install program.
610 The important thing here is the "-m 4xxx", because this wants to set the
611 setuid bit. Some install scripts throw in a "-o root" for good measure
612 when installing an otherwise normal binary. In that case it's enough that
613 the install wrapper strips out the "-o root" and you don't have to take
614 further action. But when, as in the case of inetutils, the permissions
615 indicate an attempt to make a binary setuid or setgid, then you will have to
616 investigate. You need to decide if you want rsh to be setuid root and
617 if you decide you do, you need to become root and issue commands like this:
619 chown root /usr/bin/rsh
620 chmod u+s /usr/bin/rsh
623 Be conservative with making binaries setuid. If you're unsure whether you
624 will ever use a program (as non-root), you probably don't want it to be
625 setuid root. Keep in mind that you can always make the change later when
626 you need it. When you apply this reasoning to rsh, for instance, you'll
627 probably end up not making it setuid root.
630 Example 2: "*** chgrp tty /usr/bin/write"
631 This is output by the chgrp wrapper during the util-linux installation.
632 The util-linux package wants to install the write program as setgid tty,
633 so that it is allowed to access other users' terminals. The chgrp wrapper
634 prevents the changing of the group and the chmod wrapper prevents the
635 setting of the setgid bit. You need to decide if you want the
636 program to be setgid and if you decide in favor of this, do as root
638 chgrp tty /usr/bin/write
639 chmod g+s /usr/bin/write
642 Example 3: "*** install -d -m 755 /sbin"
643 This is also from the util-linux installation. Util-linux, for no good
644 reason, tries to recreate the /sbin directory. The install wrapper
645 prevents this and you don't have to take any further action.
648 5.3 add_package_user/install_package
649 ------------------------------------
651 Whenever you install a new package on your system, you first have to create
652 a new user account, possibly create a new group and if you follow the advice
653 from this hint about making productive use of a package user's home directory,
654 you will have to set up that one, too. If you were to do all of this manually,
655 it would be a lot of work. The add_package_user and install_package scripts
656 in the more_control_helpers archive were written to automate this.
658 The install_package script is the one you will normally use to prepare for
659 installing a new package. It takes 3 parameters: the description of the
660 package, the name of the package user account to create and the name of the
661 package user's primary group. So if you use the user=group scheme recommended
662 by this hint and are as creative with your package descriptions as I am, then
663 the command you'll use to prepare for installing package "foo" will be
665 install_package foo foo foo
667 This command does 2 things. First it calls the add_package_user script with
668 the provided name, group and description plus sensible default values for
669 add_package_user's other parameters. Then, after add_package_user has created
670 the package user account, install_package automatically uses the su-command
671 to switch to the newly created account. If the default .bashrc and
672 .bash_profile scripts you use for package users contain the command "cd" as do
673 the examples in the more_control_helpers archive, you will be put right into
674 your package user's home directory so that you can start installing right away.
676 The add_package_user script is responsible for the actual work of creating
677 a new package user account. Given a name, a group name and a description, it
678 will create a new user account with the provided primary group and the install
679 group as supplementary group. The groups will be created if necessary.
680 add_package_user takes several arguments that determine the numeric ranges from
681 which it will pick the new user's UID and the GIDs for groups it needs to
682 create. add_package_user does not only create the package user account. It
683 will set up a home directory for it, too. You can either specify the directory
684 or go with the default, which is /usr/src/<name>, where <name> is the name
685 provided for the new account. If the home directory already exists, its
686 ownership and that of any existing contents will be changed to the new user.
687 If it doesn't exist, it will be created.
689 The contents of /etc/pkgusr/skel-package will be copied into the new package
690 user's home directory (without overwriting pre-existing files).
691 The more_control_helpers archive contains an example of a useful skel-package
692 directory. Note that symlinks are copied as symlinks, so skel-package is the
693 perfect place to put .bashrc and .bash_profile symlinks to a central location
694 that will ensure that all package user accounts have the same environment.
695 This is especially useful to make sure that all package users have the
696 wrappers directory in their PATH.
699 5.4 forall_direntries_from
700 --------------------------
702 The forall_direntries_from script is a very useful tool for common package
703 management tasks. It can roughly be described as a shortcut for
704 "find / -user <name> -or -group <name> <commands>", where <name> is the
705 first parameter to forall_direntries_from and <commands> are the remaining
706 parameters. However, forall_direntries_from takes care of making sure that
707 only relevant filesystems are scanned and shields you from certain unpleasant
708 surprises such as "Oops, I forgot that -depth negates -prune and have
709 accidentally wiped out my home directory." or "Oops, I forgot to -prune /proc
710 and now I'm getting parity errors on my SCSI bus.".
712 IMPORTANT NOTE: By default the forall_direntries_from script will only scan
713 the / filesystem and will not traverse other filesystems. If you have
714 relevant directories that need to be scanned on other filesystems, you will
715 need to edit the script and add the respective mount point(s) to the
716 fs_to_scan list at the beginning of the script. The most likely candidate for
719 Application examples:
721 Example 1: Create a tar.gz archive of all files that belong to <package>, e.g.
722 for installing <package> on another machine without having to
725 forall_direntries_from <package> -fprint0 /tmp/files.lst
726 tar --null -P -czf /tmp/archive.tar.gz --files-from=/tmp/files.lst
729 Example 2: Print out all setuid root binaries installed by <package>.
730 (This only works if you use the user=group scheme.)
732 forall_direntries_from <package> -perm +u+s -print
735 Example 3: List all binaries in /bin and /usr/bin belonging to "me" (i.e. the
736 package user executing the command) in alphabetical order.
738 forall_direntries_from $(whoami) -path "*/bin/*" -printf "%f\n" | sort
741 Example 4: Uninstall <package>.
743 See following section about the uninstall_package script.
746 5.5 uninstall_package
747 ---------------------
749 The uninstall_package script is basically a forall_direntries_from
750 application example in script form. The command `uninstall_package foo'
751 prints out the forall_direntries_from call that you have to use to delete
752 all the files of package "foo" (except for those in directories that
753 forall_direntries_from is instructed not to scan) together with some
754 explanations. So in order to delete the files from package foo, you would
755 execute `uninstall_package foo' and then copy'n'paste the command it prints
756 to the command line. As a safeguard the forall_direntries_from call has an
757 "echo" in front of the "rm" and "rmdir" calls, so if you execute it, the files
758 will not actually be deleted unless you remove both instances of "echo".
759 It is recommended that you execute the command once with the echos and check
760 the output to make sure that only the files you intend to be deleted are in
761 the list. After you've confirmed that, you can use the shell's history to
762 recall the command, edit out the instances of "echo" and remove the files
766 5.6 list_suspicious_files/list_suspicious_files_from
767 ----------------------------------------------------
769 list_suspicious_files looks for filesystem entries that are out of the ordinary
770 in some way and prints a categorized list of them. Things that qualify as
771 suspicious include setuid and setgid binaries, world-writable files, symlinks
772 that are possibly broken, hard links, install directories with unusual
773 permissions and other stuff. You should run this script after you've finished
774 your new LFS system and in regular intervals after that. Investigate the
778 When you check the list of setuid and setgid files, don't forget to
779 look at the actual user or group ownership of the file. It's easy to forget
780 that, especially in the setuid case, because we often equate setuid with
781 setuid root since setuid is seldom used with other user accounts.
783 list_suspicious_files_from takes a user or group name or a UID/GID as an
784 argument and reports suspicious entries only when they are owned by the given
785 user or group. Usually you would not call this script directly but instead
786 use list_package (described in the next section), whose output includes that
787 from list_suspicious_files_from.
789 IMPORTANT NOTE: By default the list_suspicious_files script will only scan
790 the / filesystem and will not traverse other filesystems. If you have
791 relevant directories that need to be scanned on other filesystems, you will
792 need to edit the script and add the respective mount point(s) to the
793 fs_to_scan list at the beginning of the script. The most likely candidate for
800 list_package tells you everything about a package's installed files. In
801 general you will want to execute something like
803 list_package $(whoami) >pkg.lst
805 right after installing a package and you can forget about the chronically
806 inaccurate content listings in the (B)LFS book.
807 The following (shortened) output for util-linux speaks for itself:
809 PS1> list_package util-linux
811 EXECUTABLES (in */bin or */sbin)
812 agetty, arch, blockdev, cal, cfdisk, [...] vidmode(->rdev), whereis, write
814 EXECUTABLES WITH NO MANPAGE (in */bin or */sbin)
815 fsck.cramfs, mkfs.cramfs
817 MANPAGE SUMMARIES OF EXECUTABLES (in */bin or */sbin)
818 agetty: alternative Linux getty
819 arch: print machine architecture
820 blockdev: call block device ioctls from the command line
821 cal: displays a calendar
822 cfdisk: Curses based disk partition table manipulator for Linux
823 chkdupexe: find duplicate executables
824 col: filter reverse line feeds from input
826 swapon: enable/disable devices and files for paging and swapping
827 tailf: follow the growth of a log file
828 tunelp: set various parameters for the lp device
830 umount: unmount file systems
831 vidmode: query/set image root device, RAM disk size, or video mode
832 whereis: locate the binary, source, and manual page files for a command
833 write: send a message to another user
836 /usr/share/man/man5/fstab.5
837 /usr/share/man/man5/nfs.5
838 /usr/share/man/man8/sln.8
840 EXTRA EXECUTABLES (not in */bin or */sbin)
841 /usr/share/misc/getopt/getopt-parse.bash
842 /usr/share/misc/getopt/getopt-parse.tcsh
843 /usr/share/misc/getopt/getopt-test.bash
844 /usr/share/misc/getopt/getopt-test.tcsh
861 /usr/share/man/man8/rootflags.8
862 /usr/share/man/man8/setfdprm.8
863 /usr/share/man/man8/setsid.8
864 /usr/share/man/man8/sfdisk.8
865 /usr/share/man/man8/sln.8
866 /usr/share/man/man8/swapoff.8
867 /usr/share/man/man8/swapon.8
868 /usr/share/man/man8/tunelp.8
869 /usr/share/man/man8/umount.8
870 /usr/share/man/man8/vidmode.8
871 /usr/share/misc/getopt
872 /usr/share/misc/getopt/getopt-parse.bash
873 /usr/share/misc/getopt/getopt-parse.tcsh
874 /usr/share/misc/getopt/getopt-test.bash
875 /usr/share/misc/getopt/getopt-test.tcsh
878 -rwsr-xr-x "/usr/bin/mount" root:util-linux
879 -rwsr-xr-x "/usr/bin/umount" root:util-linux
882 -rwxr-sr-x "/usr/bin/write" util-linux:tty
884 FILES WITH UNUSUAL PERMISSIONS
885 -rwsr-xr-x "/usr/bin/mount" root:util-linux
886 -rwsr-xr-x "/usr/bin/umount" root:util-linux
887 -rwxr-sr-x "/usr/bin/write" util-linux:tty
890 Note: list_package works regardless of the prefix you've installed the package
891 with, so you can for instance configure with --prefix=/opt/package and
892 list_package will work just fine (provided that /opt is on a
893 filesystem configured to be scanned by forall_direntries_from and
894 list_suspicious_files).
896 Note: list_package only considers manpages actually owned by the package to
897 list. It will not consider manpages installed by another package. This
898 means that you may see executables identified as not having a manpage
899 although they do have one courtesy of another package
903 5.8 grep_all_regular_files_for
904 ------------------------------
906 This script is not really related to the package user system, but because of
907 its similarity to the other scripts I've included it anyway. The sole purpose
908 of this script is to identify files that store references to the build
909 environment, specifically the /tools directory. Such references may point out
910 problems, since the /tools directory is supposed to be transient.
911 Don't forget that results for unstripped binaries and libraries are not
912 reliable, because debugging information often includes references to the
913 build environment. These do not cause trouble (unless you're trying to debug
914 the objects in question after deleting /tools).
916 IMPORTANT NOTE: By default the grep_all_regular_files_for script will only scan
917 the / filesystem and will not traverse other filesystems. If you have
918 relevant directories that need to be scanned on other filesystems, you will
919 need to edit the script and add the respective mount point(s) to the
920 fs_to_scan list at the beginning of the script. The most likely candidate for
924 5.9 The etc Directory
925 ---------------------
927 If you follow the instructions provided in the LFS-specific part of this hint,
928 the contents of the etc directory will be installed in /etc/pkgusr. The
929 directory contains a bashrc and bash_profile for package users that takes
930 care of package user specific details such as putting the wrappers directory
931 at the beginning of the PATH and calling cd, so that `su <package>' will
932 put you right into the package user's home directory. Also contained in the
933 etc directory is a skel-package directory as used by
934 install_package/add_package_user to populate the home directories of newly
935 created package users.
941 3 files in the more_control_helpers archive are only used during the
942 installation of the base LFS system and are not installed permanently.
943 The first of them is the installdirs.lst file that contains a list of
944 directories that should be install directories.
945 The second file is sbin/useradd, which is a very primitive shell script that
946 adds a new entry to /etc/passwd. It allows us to add package users before
947 we have installed shadow, which provides a real useradd.
948 Finally there is groupadd, which is like useradd, only for /etc/group.
949 Both scripts, useradd as well as groupadd, do very little error checking and
950 only support the syntax needed by install_package/add_package_user. So don't
951 try anything funky with them.
954 ------------------------ PART 2: LFS Specifics ------------------------------
957 #############################################################################
958 6. Pre-Chroot Phase (Chapter 5)
959 #############################################################################
961 Build Chapter 5 exactly as explained by the LFS book. There is only one
962 little change you have to make. After running `make install' for the coreutils
963 package, issue the following command (still from within the coreutils
968 This installs the su binary. Coreutils doesn't install su when working as
969 non-root (which we do in Chapter 5), because su needs to be setuid root for
970 normal operation and a non-root user cannot install setuid root binaries.
971 But for our purposes (i.e. su'ing from root to a package user) a non-setuid
972 su is enough, so we just copy coreutils' su to /tools/bin without making it
975 When you have reached the end of Chapter 5, before you begin with Chapter 6
976 you will need to install the helper scripts in the /tools directory so that
977 they are available once you've entered the chroot environment. Use the
978 following commands to install the more_control_helpers in /tools:
981 tar xjf /path/to/more_control_helpers.tar.bz2 &&
982 cd more_control_helpers &&
983 cp ./sbin/* /tools/bin
985 Note that the target directory is "/tools/bin" in the cp command and
986 *not* "/tools/sbin", although the latter location would be more appropriate.
987 The reason for this is simply that the LFS instructions do not add
988 "/tools/sbin" to the PATH (and neither do the instructions in this hint).
991 #############################################################################
992 7. Chroot Phase (Chapter 6)
993 #############################################################################
998 Enter the chroot environment and follow the instructions from the book up to
999 but *not* including the installation of the first package (which at the time of
1000 this writing is linux-libc-headers). Now install the more_control_helpers
1001 files in their proper locations on the new LFS system:
1003 cp -a /tools/more_control_helpers/etc /etc/pkgusr &&
1004 chown -R 0:0 /etc/pkgusr &&
1005 cp -a /tools/more_control_helpers/lib /usr/lib/pkgusr &&
1006 chown -R 0:0 /usr/lib/pkgusr &&
1007 cp /tools/more_control_helpers/bin/* /usr/bin &&
1008 cp /tools/more_control_helpers/sbin/* /usr/sbin &&
1009 rm /usr/sbin/{useradd,groupadd}
1011 Note that the useradd and groupadd scripts are not installed on the new LFS
1012 system. These scripts are just temporary workarounds we will use as long as
1013 the real useradd and groupadd are not available. Therefore they should only
1016 ATTENTION! If you decide to use a different directory than /usr/lib/pkgusr
1017 for the wrappers, you have to be careful, because at least the glibc
1018 configure script ignores certain directories when looking for programs. The
1019 list of ignored directories for glibc includes, among others, everything that
1020 starts with "/etc", "/usr/etc" and "/sbin". Wrappers put into a directory that
1021 matches any of these patterns would be ineffective.
1023 Now it's time to create the install group:
1025 groupadd -g 9999 install
1027 The GID 9999 has been chosen because the default range used by
1028 add_package_user for package user GIDs starts at 10000. Choose whatever number
1031 Once the install group has been created you have to turn all the directories
1032 that packages will install files in into install directories. To make this
1033 easier I have compiled a list of install directories that can be found in
1034 the file /tools/more_control_helpers/installdirs.lst. The following command
1035 uses this list to assign the necessary directories to the install group.
1036 Note that you will get several error messages because of non-existent
1037 directories. This is because the list contains some directories not created
1040 chown 0:9999 $(cat /tools/more_control_helpers/installdirs.lst)
1042 To be usable by package users, the directories will have to be group-writable
1043 and should be sticky as has been explained in the beginning of this hint.
1044 The following command sets the permissions appropriately.
1045 You will get the same error messages as for the previous command.
1047 chmod ug=rwx,o=rxt $(cat /tools/more_control_helpers/installdirs.lst)
1050 7.2 Walkthrough: Installing linux-libc-headers
1051 ----------------------------------------------
1053 At this point everything has been set up for creating the first package
1054 user. At the time of this writing the first package installed in the LFS
1055 book is Linux-Libc-Headers, so this package will serve as an example for how
1056 things are done. The command
1058 install_package 'Linux Headers' linux-libc-headers linux-libc-headers
1060 will create a package user with user and group name linux-libc-headers.
1061 If you don't want to use the user=group scheme, change the last argument to
1062 the desired group name. The description is arbitrary but needs to meet the
1063 requirements for the description field of an /etc/passwd entry.
1065 The directory /usr/src/linux-libc-headers will be set up as the home directory
1066 for the package user, automatically populated with the contents of
1067 /etc/pkgusr/skel-package. The install_package command also issues the command
1068 `su linux-libc-headers' to assume the identity of the newly created package
1069 user. If you're using the bashrc and bash_profile scripts from the
1070 more_control_helpers archive, you will be put straight into the directory
1071 /usr/src/linux-libc-headers and your prompt will look like this
1073 package linux-libc-headers:/usr/src/linux-libc-headers>
1075 to show you that you're working as package user linux-libc-headers and
1076 that your current working directory is /usr/src/linux-libc-headers.
1082 to verify that your PATH starts with "/usr/lib/pkgusr", the directory that
1083 contains the wrappers, and ends with "/tools/bin".
1085 Now everything is prepared for installing the package according to the
1086 instructions in the LFS book. Note that at the time of this writing the
1087 LFS book tells you to execute a chown command to make sure that the headers
1088 are owned by root. This is just because the packager has made a very common
1089 mistake when creating the tarball for the headers: He has archived the files
1090 with a non-root user/group assignment. When unpacking such a tarball as root,
1091 the files end up being owned by some weird user/group combination, which may
1092 open a security hole. When you're working as a package user this can not
1093 happen and you don't want to chown the headers to root:root, because that
1094 would defeat the whole point of installing the headers with a package user.
1095 This is one of the small points on which you will have to deviate from the
1096 standard LFS instructions when using package users. More package user related
1097 issues with the current LFS book can be found in the next section.
1099 After you've installed the headers, simply issue the command
1103 to become root again. Now would be a good time to think about useful
1104 customizations for /etc/pkgusr/{bash_profile,bashrc} and/or
1105 /etc/pkgusr/skel-package, if you've not already customized them.
1106 Once you're satisfied with your setup, install the rest of the packages.
1107 The following section will help you with some problems that you will run into.
1110 7.3 Known Issues with LFS Packages
1111 ----------------------------------
1113 This section has details on the package user related problems you will face
1114 when building your LFS system. You should copy the information from this
1115 section to the INSTALL NOTES of the relevant .project files for the packages
1116 concerned, together with any of your own notes.
1118 NOTE: If you're building by an LFS book later than 6.0 it is recommended that
1119 you read this complete chapter before you start building any packages.
1120 If your LFS version is 6.0 then it's fine to read this section package
1121 by package as you progress with your build.
1125 At the time of this writing the LFS book tells you to execute a chown
1126 command to make sure that the headers are owned by root. This is just
1127 because the packager has made a very common mistake when creating the
1128 tarball for the headers: He has archived the files with a non-root
1129 user/group assignment. When unpacking such a tarball as root, the files
1130 end up being owned by some weird user/group combination, which may open
1131 a security hole. When you're working as a package user this can not happen
1132 and you don't want to chown the headers to root:root, because that would
1133 defeat the whole point of installing the headers with a package user.
1135 There's another packaging error in the linux-libc-headers archive.
1136 The files are stored with incorrect permissions. They are supposed to
1137 be world-readable, but they are not. The book's instructions already
1138 tell you how to correct this but I point it out, because this error will
1139 resurface a little later.
1143 If the name you use for the man-pages package user is not exactly
1144 "man-pages", then you will have to change the variable "manpagesowner"
1145 right at the beginning of the wrapper script `install'.
1147 Recent versions of man-pages contain POSIX manpages that the package
1148 tries to install in /usr/share/man/man{0,1,3}p. As /usr/share/man is
1149 not an install directory and the LFS book does not have instructions to
1150 create these directories at the time of this writing, the installation
1151 will fail and the respective man-pages will not be installed.
1153 1. Make /usr/share/man an install directory.
1154 Consequence: All Packages will be able to create new subdirectories
1155 in /usr/share/man. I find this undesirable because there are packages
1156 that create directories for manpages in foreign languages that I
1158 2. Ignore the problem and live without the POSIX manpages. Unless
1159 you are a developer (including script writer) who is interested
1160 in writing portable programs/scripts this is a good solution.
1161 3. Create the directories /usr/share/man/man{0,1,3}p as root
1162 prior to installing man-pages. You'll have to either chown them
1163 to the man-pages package user or make them install directories.
1164 This is my preferred solution.
1168 The packaging error of libc-linux-headers described earlier also affects
1169 the glibc build. Because of the error, the headers in /tools/include
1170 are not world-readable. Unfortunately the LFS book (as of this writing)
1171 does not correct this in Chapter 5 like it does in Chapter 6. For a
1172 standard LFS build this is no problem, because glibc is built as root and
1173 root can access everything regardless of permissions.
1174 The glibc package user, however, does not have permission to access
1175 these headers. This will cause several configure tests to fail, because
1176 the respective test programs can not be compiled.
1177 The end result is the error message "/lib/cpp fails sanity check", which
1178 is completely nonsensical as we don't have a /lib/cpp.
1180 This is the perfect opportunity to introduce rule #1 of error diagnostics:
1182 NEVER TRUST DIAGNOSTIC MESSAGES !
1184 There are 2 kinds of diagnostic messages:
1186 1. Those that are unnecessary, because once you see which component has
1187 failed, the source of the problem is obvious.
1188 2. Those that grossly misdiagnose the source of the problem and lead
1189 you to draw the wrong conclusions.
1191 No, there is no other kind. Trust me ;-)
1192 In this case, /lib/cpp has nothing to do with the problem. It doesn't
1193 exist and that's fine. The message just wants to trick you into doing
1194 something stupid such as create a symlink /lib/cpp -> /tools/bin/cpp.
1195 But that would be totally wrong. Before you jump to any premature
1196 conclusions you should always try to get as much *low-level* information
1197 as you can. Diagnostic messages are *high-level* information. They
1198 represent a filtered view of the problem, which is usually of little help.
1199 Fortunately the message (the complete one, not the part quoted above) also
1200 points at the source for the necessary low-level information. In this
1201 case that is the file config.log (not to be confused with configure.log,
1202 the file created by the build script included in the more_control_helpers
1204 config.log is created by all autoconf-created configures (not just that
1205 of glibc) and it contains, among other things, the test programs used by
1206 configure and messages output while building and running them. Whenever a
1207 configure script fails or gives weird results, check config.log. And
1208 always remember rule #2 of error diagnostics
1210 ALWAYS START AT THE FIRST ERROR
1212 This seems pretty obvious, but nevertheless people commonly do the exact
1213 opposite. It's just too tempting to start at the point of the final
1214 failure and try to work backwards. In this case many people would open
1215 config.log and scroll to the point of the failed /lib/cpp sanity check.
1216 After all, that's what caused configure to abort and so that's what needs
1217 to be fixed, right? WRONG! Someone who takes this approach just sees the
1218 error message "/lib/cpp: No such file or directory" and is even more
1219 convinced that a missing /lib/cpp symlink (or program) is the problem.
1221 The correct way to approach such a problem is to start at the beginning
1222 of config.log, to scroll down to first error message and to check if it
1223 is an issue that needs to be fixed (error messages in config.log are
1224 not always signs for a problem). If the issue needs to be fixed, then
1225 it needs to be fixed first, because all later errors could be rooted in
1226 this issue (even if, no, *especially* if you don't believe this is the
1228 If we apply this advice to the problem at hand, we quickly get to the first
1229 serious error in config.log:
1231 "/tools/include/linux/limits.h: Permission denied"
1233 A quick check with ls reveals that indeed the directory with the linux
1234 headers is not world-readable, which is obviously wrong. The fix is
1235 easy. Just make (as root) the header directories /tools/include/{linux,asm}
1236 world-readable with commands similar to those the LFS book presents
1237 in Chapter 6 for the installation of linux-libc-headers.
1238 Once this change has been made, glibc's configure succeeds.
1241 Even when configure completes successfully, you should still check the
1242 output carefully to see if there is anything odd. E.g. if you're using
1243 the wrappers, you should check that configure outputs the line
1245 checking for a BSD-compatible install... /usr/lib/pkgusr/install -c
1247 If configure detects a different install, such as /tools/bin/install,
1248 something is wrong. Maybe there's a typo in the PATH for the package
1249 user, or you've put the wrappers into a directory that is ignored by
1253 With the wrappers the glibc build and install should work smoothly.
1254 The wrapper script for install makes sure that the /usr/share/locale/*
1255 directories become install directories so that other programs can install
1256 their localized messages. One thing that the wrappers do not take care of,
1257 however, is the file /usr/share/info/dir. Because in the current LFS build
1258 order glibc is the first package that installs info files, dir is owned by
1259 and only writable by glibc. In order to allow other packages to install
1260 info pages, execute the following commands as root:
1262 chown root:install /usr/share/info/dir &&
1263 chmod ug=rw,o=r /usr/share/info/dir
1266 glibc wants to install the program pt_chown as setuid root. If you install
1267 as a package user, the program will get installed but not given root
1268 privileges (because of the install wrapper).
1269 The following info is from the glibc docs:
1271 One auxiliary program, `/usr/libexec/pt_chown', is installed setuid
1272 `root'. This program is invoked by the `grantpt' function; it sets the
1273 permissions on a pseudoterminal so it can be used by the calling
1274 process. This means programs like `xterm' and `screen' do not have to
1275 be setuid to get a pty. (There may be other reasons why they need
1276 privileges.) If you are using a 2.1 or newer Linux kernel with the
1277 `devptsfs' or `devfs' filesystems providing pty slaves, you don't need
1278 this program; otherwise you do. The source for `pt_chown' is in
1279 `login/programs/pt_chown.c'.
1281 So unless you're building a system that does not use devpts (which would
1282 be quite unusual), this does not need to concern you.
1285 In case you were wondering if you should create /etc/nsswitch.conf and
1286 /etc/ld.so.conf as root or glibc, I recommend to assign all files that
1287 you manually create or manually edit to the root account. That way you can
1288 distinguish between those files that can be regenerated automatically and
1289 those that can not. Assigning even automatically generated files to
1290 root once you make the first manual edit, ensures that a later
1291 reinstallation of a package won't silently do away with your manual tweaks.
1295 The installation of binutils should complete without problems.
1296 It does however cause minor conflicts with autoconf (see later).
1300 Because the /usr/lib/libgcc_s.so.1 symlink created at the beginning of
1301 Chapter 6 is owned by root, gcc's installation cannot remove it.
1302 So you will have to remove it as root before `make install'.
1306 Because the /bin/cat, /bin/pwd and /bin/stty symlinks are owned by root,
1307 coreutils' installation cannot remove them. So you will have to remove
1308 them manually before `make install'.
1311 The man-pages package has already installed manpages for the binaries
1312 from coreutils. The install wrapper will prevent coreutils from overwriting
1313 those. This is done because the manpages from the man-pages package are
1314 of superior quality. It also prevents errors during `make install' that
1315 would otherwise occur because the coreutils package user cannot overwrite
1316 manpages owned by another user.
1317 If you don't like the above behaviour and would rather have the original
1318 package manpages (despite them being inferior), you can set the variable
1319 manpagesowner at the beginning of the install wrapper to a string that
1320 doesn't correspond to a package user name (it must not be empty, though!).
1321 If you do this, you will have to resolve manpage conflicts in another way.
1322 The easiest way to handle this is probably to not install the man-pages
1323 package at the beginning of Chapter 6 but at the end, after all the other
1324 packages have already installed their manpages. Then you need only deal
1325 with the conflicts once, when installing man-pages.
1329 The installation of ncurses (like that of other packages that include
1330 libraries) wants to run /sbin/ldconfig to update /etc/ld.so.cache.
1331 This fails because the package user doesn't have permission to replace
1333 Making /etc/ld.so.cache group-writable by the install group doesn't help,
1334 because the permissions would be reset on the next call to /sbin/ldconfig.
1335 This error will usually not abort the installation and you can just
1336 run /sbin/ldconfig manually as root afterwards.
1340 The gettext installation creates the directory /usr/share/aclocal, which
1341 contains macros for autoconf. Other packages want to install
1342 files into this directory, so you should make it writable by the install
1343 group and sticky. You don't need to do this now. You can wait till you
1344 install a package that wants to write to aclocal.
1348 This package contains some programs that it wants to be setuid root:
1349 rsh, rcp, rlogin and ping
1350 The install wrapper prevents these programs from being installed
1351 setuid root. You must decide which of these programs you want to be
1352 setuid root and manually make them so. Be conservative. Don't make a
1353 binary setuid root unless you *know* that ordinary users can't live
1354 without it. Every setuid root binary is a potential security hole.
1358 This package tries to change the permissions of /usr/sbin. The install
1359 wrapper takes care of this.
1363 Before you do `make install', you will have to
1364 `chown perl /usr/bin/perl' so that the perl package user is allowed to
1365 remove the /usr/bin/perl symlink.
1367 If you will install add-on packages for perl as their own package users
1368 into /usr/lib/perl5/site_perl, then you will need to turn
1369 /usr/lib/perl5/site_perl/ and its subdirectories into
1370 install directories. You don't need to do this now as you'll notice it
1371 anyway when installing a perl add-on fails.
1375 The autoconf package wants to install its own copy of standards.info,
1376 which fails because binutils has already installed this file. You can
1377 either ignore the error or remove the binutils version of standards.info
1378 before `make install'.
1382 Before you can `make install' you need to `chown bash /bin/bash' so
1383 that the bash installation can replace the /bin/bash symlink.
1384 When running the test suite as a package user, the test "run-test" will
1385 fail with the following output:
1388 < *** chmod g+s /tmp/test.setgid
1394 < *** chmod u+s /tmp/test.setuid
1408 The first 2 failures are caused by the chmod wrapper which prevents the
1409 test from setting the setuid and setgid bits and outputs the *** warning.
1410 The failures are harmless and will not occur if you remove the wrappers
1411 directory from the PATH before running the tests.
1413 The last 2 failures are not specific to package users but will occur
1414 whenever the user running the test is not the user who owns the terminal
1415 as is usually the case when you use the `su' command.
1416 Simply ignore these failures. They are harmless. If you insist on getting
1417 the tests to succeed, you will have to use chown as root to
1418 assign ownership of the tty in which you will run the tests to the
1419 user running the tests. To find out the proper terminal, use the command
1420 `ls -la /proc/self/fd/1' in the terminal where you will run the tests.
1421 It will output something like
1422 lrwx------ 1 bash bash 64 Sep 12 21:29 /proc/self/fd/1 -> /dev/pts/2
1423 In this example the tty to be chowned would be /dev/pts/2.
1427 The libtool installation wants to add files to /usr/share/aclocal, so
1428 if you have not made it an install directory, yet, you will have to do it
1429 now (i.e. make the directory group install, group-writable, sticky).
1433 The commands to create and populate /boot/grub have to be executed as
1438 The procps installation wants to execute the command `ldconfig'. This will
1441 1) A package user does not have /sbin in its PATH
1442 2) Package users are not allowed to overwrite /etc/ld.so.cache
1444 To overcome this problem, install with
1446 make ldconfig='' install
1448 and issue the command `/sbin/ldconfig' manually as root after installing.
1452 shadow contains its own version of the `groups' command and accompanying
1453 manpage. The installation of these conflicts with the coreutils versions.
1454 As of this writing the LFS book deals with this problem in
1457 1) coreutils' groups is installed in /usr/bin and shadow's
1458 groups is installed in /bin, so it's enough to delete shadow's groups
1460 2) The manpage issue is simply ignored, meaning that the system will
1461 end up having the coreutils version of groups but the shadow version
1462 of the groups manpage.
1464 Number 1 will not cause trouble with package users, unless you
1465 are doing things like symlinking /usr/bin and /bin to be the same. And in
1466 that case the "trouble" caused, namely that shadow won't be able to
1467 overwrite `groups', is actually a good thing, because it prevents you
1468 from unknowingly ending up with a different `groups' command than a
1469 standard-LFS user. Issues like this are exactly what the "more control"
1470 part of this hint's title is about. The package user system does not
1471 allow things like this to happen behind your back.
1473 Number 2 is probably not intentional. It's just one of those things that
1474 people who don't use the package user system never become aware of and so
1475 it has managed to escape the attention of the LFS testers. So once again
1476 the installation failure caused by the package user system, although
1477 annoying, is a desirable feature.
1479 To deal with both groups-issues, simply prevent shadow from installing
1480 groups and its manpage. Execute the following commands *after* the
1481 configure step, because the Makefiles don't exist until then.
1483 sed -i 's/groups.1//' man/Makefile
1484 sed -i '/^bin_PROGRAMS/s/groups//' src/Makefile
1486 By default shadow wants to install non-English manpages. This fails
1487 because the /usr/share/man directory is not an install directory and
1488 therefore package users are not allowed to create new subdirectories in it.
1489 To solve this problem, before you `make install', open the file
1490 man/Makefile, find the line
1492 SUBDIRS = cs de es fr hu id it ja ko pl pt_BR ru zh_CN zh_TW
1494 and remove all the languages that you don't want to install. For those
1495 languages that you do want to install, create directories with the
1496 respective names in /usr/share/man as root and make them install
1497 directories (i.e. group install, group-writable, sticky).
1499 At the time of this writing the coreutils patch used in LFS prevents the
1500 installation of the su binary, but not of its manpage. This is probably
1501 another buglet in LFS that is exposed by the package user system.
1502 Whatever the reason, you will have to remove the su.1 manpage manually
1503 as root before shadow can be installed:
1505 rm /usr/share/man/man1/su.1
1507 There is yet another issue with shadow concerning manpages. The shadow
1508 package contains a passwd.5 manpage. Installation of this manpage is
1509 automatically suppressed by the install wrapper, because it would
1510 overwrite the passwd.5 manpage provided by the man-pages package. As usual
1511 the man-pages version is better, so you can simply ignore this issue.
1513 shadow wants to install the programs su, chage, chfn, chsh, expiry,
1514 gpasswd, newgrp and passwd as setuid root. You will need to decide which
1515 of these programs you want to be setuid root and manually make them so.
1519 sysklogd's Makefile has /usr/bin/install hardwired as the install
1520 program, which circumvents the install wrapper. The wrapper is needed
1521 for sysklogd because it tries to make its manpages owned by root
1522 (which obviously a package user is not allowed to do).
1523 Therefore, install with
1525 make INSTALL=install install
1529 sysvinit's installation wants to create /dev/initctl if it does not exist,
1530 but a package user does not have permission to do that, so create
1531 /dev/initctl manually as root before installing:
1535 chmod 600 /dev/initctl
1539 udev wants to recreate the /dev directory, although it already exists.
1540 Since a package user cannot do that, the installation fails. To fix this,
1541 kill the line in the Makefile that's responsible:
1543 sed -i '/\$(INSTALL) -d \$(DESTDIR)\$(udevdir)/d' Makefile
1545 NOTE: udev's Makefile is read-only, but apparently sed doesn't care about
1546 this. If you want to edit the Makefile in another way (or if you're using
1547 a sed version that doesn't have this, IMHO buggy, behaviour), you will
1548 have to `chmod u+w Makefile' first.
1552 util-linux wants to install write as setgid tty and u/mount as
1553 setuid root. The wrappers catch this, so it doesn't cause the install to
1554 fail, but as usual you'll have to decide if you want these programs to
1555 have special privileges and take manual action as root if you do.
1558 ##########################################################################
1560 ##########################################################################
1562 8.1 Suspicious Files
1563 --------------------
1565 You probably ran the `list_package' command for each package and reviewed
1566 the results which include the suspicious files owned by that package. But even
1567 if you did that it's still a good idea to run the non-package specific
1568 `list_suspicious_files' command once your build is complete. There could be
1569 something you overlooked the first time, or maybe you created a file as root
1570 with the wrong permissions. It doesn't hurt to check again and this will also
1571 give you the opportunity to review any setuid/setgid decisions you made with
1572 respect to the installed binaries.
1575 When you check the list of setuid and setgid files, don't forget to
1576 look at the actual user or group ownership of the file. It's easy to forget
1577 that, especially in the setuid case, because we often equate setuid with
1578 setuid root since setuid is seldom used with other user accounts.
1581 8.2 References to Temporary Files
1582 ---------------------------------
1584 One big concern when building an LFS system is independence of the new LFS
1585 system from the files installed in /tools. The /tools directory is intended
1586 to be temporary and it should be possible to delete it after building your
1587 LFS system with no adverse side effects. The `grep_all_regular_files_for'
1588 script from the more_control_helpers package can help you verify that your
1589 new LFS system is indeed clean. The command
1591 grep_all_regular_files_for /tools
1593 will give you a list of all files that contain the string "/tools". Review the
1594 files in the list to make sure that no dependencies on the temporary files in
1595 /tools have crept in. But remember that results from binaries and libraries
1596 are only meaningful after stripping away the debug information, because
1597 debug information necessarily includes references to the build environment.
1598 Of course, if you are a developer who will potentially run gdb on system
1599 libraries/binaries, your position will be that stripping away debug information
1600 is the wrong way to do away with /tools references. The other way to deal with
1601 them is to rebuild packages for which /tools references are reported. The new
1602 build will not involve any files from /tools and so the new debug information
1603 will not refer to /tools. Note that the LFS build instructions for glibc
1604 make glibc compile against /tools/glibc-kernheaders. Unless you copy the
1605 glibc-kernheaders directory to a location outside of /tools and compile glibc
1606 against that copy, you won't get rid of the /tools references in glibc's
1608 No matter what means you choose to deal with the debug information issue, in
1609 the end you should have a system where the above command produces only false
1610 positives (such as "perlfaq3.1", which includes the URL
1611 "http://www.research.att.com/sw/tools/uwin/") and files that legitimately
1612 refer to /tools (such as a copy of this hint file).
1615 ----------------------------- APPENDICES ----------------------------------
1618 ###########################################################################
1619 Appendix A: Security Issues
1620 ###########################################################################
1625 If you use the network filesystem NFS, there are some things you need to
1626 look out for when using the package user system. A fundamental security
1627 problem with NFS is that it blindly trusts the UID and GID of the client.
1628 If an attacker can get access to the root account on a system in your network
1629 that is allowed to mount NFS shares from your server, or if the attacker can
1630 attach his own computer to your network, then this attacker can pretend to be
1631 anyone. NFS will happily allow the attacker to work in the NFS exported
1632 directory as any user he wants to be. The only exception is the root account.
1633 By default NFS exports directories with the root_squash option that maps all
1634 incoming requests from uid 0 to anonuid (65534 unless set in /etc/exports)
1635 and gid 0 to anongid (65534 unless set in /etc/exports). This protects files
1636 owned by root:root. On a normal system this includes most files in /bin, /etc,
1637 /lib and most other directories except /home. If you use the package user
1638 scheme, however, most of these files are owned by package users. These files
1639 are not protected by the root_squash option. In order to make NFS exports
1640 secure, you have to add the option "all_squash" to every entry in /etc/exports
1641 that exports a directory that contains files owned by package users. Note that
1642 all_squash is always a good idea because even systems that don't use package
1643 users often have some programs owned by other users or groups, because they
1644 need to be setuid or setgid.
1650 It is a common practice to run daemons under special user accounts rather
1651 than as root as a security measure. If you feel tempted to use a package
1652 user account for this purpose, resist the temptation. It would be a very
1653 stupid idea. Although they are deliberately less powerful than root, package
1654 user accounts are still privileged and need to be considered as equivalent to
1655 root as far as security is concerned. Do not do anything with a package user
1656 that on a system without package users you would not do with the root account.
1659 ###########################################################################
1660 Appendix B: Package Categories
1661 ###########################################################################
1663 Although the user name = group name scheme is recommended by this hint, it is
1664 not the only possible one. Another scheme that has some appeal is to define
1665 package categories and to use the group for the purpose of categorizing the
1666 packages. Following is a suggested set of categories that can serve as a
1667 guideline for implementing this scheme.
1669 devel: development related stuff, e.g. compilers. This is not restricted to
1670 software development. TeX for instance would belong in this group.
1672 utils: Most software fits into this category, even somewhat essential software
1673 like grep or text editors.
1675 net: network related stuff such as an ftp daemon or a web browser. This
1676 group overlaps with other groups to a large extent. It should be used
1677 in preference of the other groups whenever a package is clearly focused
1678 towards Internet, LAN, WWW,... A utility like wget for instance would
1679 go in net rather than utils. Exceptions from this rule are the groups
1680 docs, addons, games and mmedia. If a package fits into one of those
1681 groups, use the respective group instead of net.
1683 docs: Documentation related packages, such as a tarball with Linux howtos.
1684 Note that software to create documentation such as XML processors should
1685 probably go in devel and software to view or post-process documentation
1686 such as man or groff should probably go in utils.
1688 system: important system software, such as bash. This group should be used
1689 only for really essential packages. Most packages you would put in
1690 this group are better put in "utils". Vi for instance belongs in
1692 It is unlikely that any package not part of basic LFS belongs in the
1695 libs: What utils is for executables, libs is for libraries. Libraries that are
1696 not strongly related to any of the other categories should go here, such
1698 Essential system libraries such as glibc, ncurses or gettext should
1699 go in system instead.
1700 The libs group is also used for run-time environments such as the
1701 Java Virtual Machine, dosemu and wine. Other emulators like MAME for
1702 instance should probably go into games instead.
1704 games: what do you expect ;-)
1706 mmedia: This is the group for audio and video editors, mp3 players etc.
1708 apps: Applications such as spreadsheets and word processors (not text editors)
1709 but also CAD software and graphics software such as Gimp.
1710 The apps group is a bit like utils, but apps are usually more user
1711 friendly and more streamlined and feel less nerdish than utils.
1713 addons: plugins, filters and similar that are meant to be used in conjunction
1714 with another package.
1716 x: software that relates to the X Window System in general and does not fit
1717 into any of the other categories, such as the X server itself or window
1719 Most X software should be put into other more specific groups.
1720 A game like xmines would go in games for instance and a text editor for
1721 X would go in utils.
1723 kde: Software that relates to KDE and does not fit into
1724 any other category. This group should be used with care.
1725 Do *not* use it for all KDE software. K Office for instance belongs in
1726 apps. Konqueror belongs in net.
1728 gnome: Software that relates to GNOME and does not fit into
1729 any other category. This group should be used with care.
1730 Do *not* use it for all GNOME software. Gimp for instance belongs
1731 in apps. A GNOME-aware window manager that works with plain X should
1735 ###########################################################################
1736 Appendix C: Acknowledgements and Changelog
1737 ###########################################################################
1740 * Tushar Teredesai for suggesting the user=group scheme.
1741 * Markus Laire for reporting the 2005-01-01 build bug
1746 -fixed list_suspicious_files and list_package to work with
1747 recent more POSIX-conforming versions of GNU find
1748 -released version 1.2
1751 -fixed bug in skel-package/build script that caused it to report
1752 all steps as successful, even if they failed
1753 -released version 1.1
1757 -released version 1.0
1760 -started developing the more_control_helpers utilities
1763 -started major rewrite (update for new LFS version, new hint
1764 format, textual improvements,...)
1767 -changed LFS VERSION header to be more conservative
1768 -added <br> tags to the synopsis for the sake of the hints
1770 -added group mmedia to the list of suggested groups
1774 -added note, that on Linux make doesn't need to be setgid kmem
1777 -added section "Security issues with NFS"
1780 2002-01-30 -added Changelog
1781 -moved "chown 0.10000 `cat /tmp/installdirs`" command up (before
1782 glibc package user is created)
1783 -add_package_user: create home directory with "mkdir -p"
1784 use $grpfile everywhere instead of /etc/group
1785 -improved mammoth sentence in Introduction
1786 -added note about possibility to have user name==group name
1787 -source bashrc_basic in bashrc_package
1788 -minor textual changes