Mercurial > pkg
view previous-work/more_control_and_pkg_man.txt @ 3:9ff0fcf34920
first draft of pkg.pl complete.
author | Robert McIntyre <rlm@mit.edu> |
---|---|
date | Tue, 08 Jan 2013 14:42:09 +0000 |
parents | d6bef198ae71 |
children |
line wrap: on
line source
2 AUTHOR: Matthias S. Benkmann <article at winterdrache dot de>4 DATE: 2007-10-206 LICENSE: Creative Commons Attribution-Share Alike 3.07 (http://creativecommons.org/licenses/by-sa/3.0/)9 SYNOPSIS: More Control and Package Management using Package Users (v1.4)11 DESCRIPTION:12 -You want to know which packages your files belong to ?13 -You want to deinstall software that doesn't have make uninstall ?14 -You are bothered by programs installed setuid root behind your back ?15 -You don't like packages quietly overwriting files from other packages ?16 -You don't like package managers like RPM ?17 -YOU WANT TOTAL CONTROL USING ONLY UNIX BUILTINS ?19 ATTACHMENTS:20 http://www.linuxfromscratch.org/hints/downloads/attachments/more_control_and_pkg_man/more_control_helpers.tar.bz222 PREREQUISITES:23 For use with LFS book 6.2: Brain.24 For use with LFS book later than 6.2: Brain (awake, good working condition).26 HINT:28 ###########################################################################29 Contents30 ###########################################################################32 1. Preface33 2. Overview35 - PART 1: General Information -37 3. Package Users38 3.1 Introduction39 3.2 User Name40 3.3 Groups41 3.4 Home Directory42 4. Common Problems43 4.1 Introduction44 4.2 General Procedure45 4.3 Permission Changes46 4.4 Ownership Changes47 4.5 Write to Non-Install Directory48 4.6 Delete or Overwrite File49 4.7 /sbin/ldconfig50 4.8 What Commands to Run as a Package User51 5. The more_control_helpers Archive52 5.1 Overview53 5.2 The Wrappers54 5.3 add_package_user/install_package55 5.4 forall_direntries_from56 5.5 uninstall_package57 5.6 list_suspicious_files/list_suspicious_files_from58 5.7 list_package59 5.8 grep_all_regular_files_for60 5.9 The etc Directory61 5.10 Temporary Files63 - PART 2: LFS Specifics -65 6. Pre-Chroot Phase (Chapter 5)66 7. Chroot Phase (Chapter 6)67 7.1 Preparations68 7.2 Walkthrough: Installing linux-libc-headers69 7.3 Known Issues with LFS Packages70 8. Sanity Checks71 8.1 Suspicious Files72 8.2 References to Temporary Files74 - APPENDICES -76 A. Security Issues77 A.1 NFS78 A.2 Daemons79 B. Package Categories80 C. Acknowledgements and Changelog83 ###########################################################################84 1. Preface85 ###########################################################################87 Let's say I have written a program that you would like to use. To make it88 easier for you I come over to install it for you. Would you give me the root89 account and then leave the room ? No ? Then why do you give it to complete90 strangers who you have never seen in your life, to install software packages91 pulled from some Internet server, that come with no warranty and don't even92 list their contents in the README, although they will happily spread them all93 over your system ?95 It is a mystery why Unix admins who wouldn't even trust their employer with96 more than a normal user account carelessly execute complex and incomprehensible97 installation scripts with full root rights.99 Users and groups are the basic security principle in a Unix system. They have100 been used successfully for a long time to monitor who has created a file and101 to control who is allowed to delete or change it. But this control has only102 been imposed on the files of ordinary users. What a waste! I suggest to extend103 this control to all system files.105 The general idea is to create package users, i.e. user accounts with restricted106 rights, to build and install software packages, rather than doing these tasks107 as root. Not only does this give you more control over what build and install108 scripts may or may not do, it can also serve as a quite useful package109 management system.112 #############################################################################113 2. Overview114 #############################################################################116 This hint is divided into 3 parts. The first part contains general information117 about the package user method. This part is the most important part of the118 hint. Read it thoroughly. The second part explains how to apply the package119 user method to the building of an LFS system.120 Finally, part 3 of this hint is the Appendix with information that would not121 fit anywhere else or that is not of general interest.123 It is inevitable that part 2 will become outdated with time as the LFS book124 changes and new versions of the software packages used with LFS are released.125 I make no attempt to track these changes.126 When someone reports an issue with a package I will incorporate127 it into the hint, but larger changes that might be required due to changes in128 the LFS build methodology could take a long time to get included. The reason129 for this (aside from lack of time) is that I consider part 2 as bonus material130 that helps people get started but is not essential. Part 1 describes the131 concepts, which are independent of package versions or the LFS book, and you132 will have to rely on this information whenever part 2 fails. Don't forget133 that part 2 only deals with the packages used by the LFS book. For all the134 other packages you install on your system after that even an up-to-date135 part 2 would offer no aid anyway.137 The previous paragraph might sound discouraging, and as you read more from the138 hint it is possible that you get the impression that the package user139 method is complicated, causes lots of difficult problems and is overall too140 much trouble for anyone but a real hardcore admin with programming experience.141 But you would be mistaken.142 First of all, many things experienced as installation problems when working143 with the package user system are in fact desirable features.144 If `make install' fails for some package, because it attempts to install a145 file with the same name as a pre-existing file from another package, you146 should not curse the fact that you have to spend additional time to resolve147 this issue. Instead you should be happy that you have been alerted of this148 collision that, had it gone unnoticed, could have messed up your system in149 more or less subtle ways.150 Secondly, the package user system is not an all-or-nothing approach. It151 works on a per-package basis. If a package gives you too much trouble, you152 can always decide to chicken out and finish the installation as root.153 Finally, the more_control_helpers archive provided with this hint contains154 several useful scripts that automate many aspects of software installation155 as a package user and, together with the tips given in this hint, add a lot156 of value to the package user system.157 So do not pass judgement until you have read at least the complete part 1,158 including the description of the more_control_helpers.161 ---------------------- PART 1: General Information --------------------------164 #############################################################################165 3. Package Users166 #############################################################################168 3.1 Introduction169 ----------------171 The basic idea of this scheme is easily explained. Every package belongs to a172 certain "package user". When you install a package, you build and install173 the package as this package user, causing all files that are installed to be174 owned by the package user. As a consequence all the usual package management175 tasks can be comfortably achieved through the use of standard command line176 utilities. A simple `ls -l <file>' will tell you, for instance, what package177 <file> belongs to and a `find -user ...' command allows you to perform an178 operation on all the files belonging to a certain package, e.g. delete them179 to uninstall the package.181 But package management is not all that package users are good for. Because182 package users do not have root-rights, the installation of a package is183 limited in what it can do. One thing that a package user is not allowed to do,184 for example, is to overwrite files from a different package user. Clashes185 between different packages that want to install a binary, library or header186 file of the same name are more common than you might think. With package users187 you never run the risk of package B's installation destroying files from188 package A silently without you noticing. Every attempt of doing this during189 package B's installation will cause a "Permission denied" or190 "Operation not permitted" error so that you have the chance of taking191 appropriate steps.192 Another thing that package users are not allowed to do is install setuid root193 binaries. The decision to make a binary setuid root is also something that a194 prudent admin does not want to leave up to the creator of a software package.196 Usually package user accounts have no valid password so that only root can su197 to a package user, which ensures that package users do not open an additional198 way into the system and undermine security. But you *may* set passwords199 anyway to allow a co-admin who you want to be able to install and maintain200 certain software packages to do so without having access to the actual root201 account. This co-admin could for instance install, delete, change additional202 libraries which might be necessary for his workgroup. He would be unable,203 though, to remove or modify libraries which don't belong to him/her, such as204 libc.207 3.2 User Name208 -------------210 You don't need to drive yourself nuts trying to come up with 8 character211 names for the package users. I always use the name of the package without212 the version number, including dashes and possibly exceeding 8 characters in213 length, e.g. "util-linux", and in the several years that I've been using this214 scheme I have not encountered any problems, nor has anyone else reported215 trouble. The 8-character limit on user names seems to be a thing of the past.217 TIP:218 You can use bash's programmable completion feature to save yourself some219 typing when entering commands that take a user name as an argument, such as220 su, finger or pinky. The command222 complete -o default -o nospace -A user su finger pinky224 tells bash to tab-complete words as user names for the commands su,225 finger and pinky.226 With this in place you can simply type `su linux-li<TAB>' and bash227 will complete this to `su linux-libc-headers' (assuming that you have a228 package user named "linux-libc-headers").229 "-o default" tells bash that if a suitable user name does not exist, the230 default completion shall be attempted.231 "-o nospace" prevents the addition of a space after the completed word.233 This is a very useful command to put into root's .bashrc and .bash_profile.235 BTW, at http://freshmeat.net/projects/bashcompletion/236 you can find a project that offers sophisticated completions for many237 other commands.239 Or switch to zsh (http://freshmeat.net/projects/zsh/). It's more powerful240 and less buggy than bash.243 3.3 Groups244 ----------246 Every package user belongs to at least 2 groups. One of these groups is247 the "install" group, which all package users (and only package users) belong248 to. All directories that packages are allowed to install stuff in belong to249 the install group. This includes directories such as /bin and /usr/bin but250 excludes directories like /root or /.251 The directories owned by the install group are always group-writable.252 This would be enough for the package management aspects, but without further253 preparation this would not give added security or control because every254 package could replace the files from a different package (the change would255 be visible in the output from `ls -l', though).256 For this reason all install directories get the sticky attribute. This257 allows users to create new files and delete or modify their own files in258 the directory, but files from other users can not be modified or removed.259 In the rest of this hint, whenever the term "install directory" is used, it260 refers to a directory that belongs to group install, is group-writable and261 sticky. IOW, to turn <dir> into an install directory you would do263 chgrp install <dir> && chmod g+w,o+t <dir>265 Although the install group is crucial for the package user system, it is266 implemented as a supplementary group, rather than as the primary group for267 package users. This has at least 2 advantages.268 One advantage is that this makes it easy to get a list of all packages269 installed on the system with the command271 grep install /etc/group273 A more important point, however, is that the primary group is the274 one that files created by the package user will belong to. So it will be275 printed in the output of `ls -l' and is subject to find's "-group" test.276 This makes it very useful for organizational purposes.277 Following are some suggestions for how to use the primary group.279 1. group name = user name281 Under this scheme the package user for the bash package would be282 bash:bash. `ls -l /bin/bash' would show something like this284 -rwxr-xr-x 1 bash bash 1731859 Feb 30 2005 /bin/bash286 An important advantage of this scheme is that the user information is287 not lost when you make a file setuid root, which requires changing288 the file's owner. Because of this advantage, this scheme is the one289 recommended by this hint. However, the hint's instructions will work290 fine if you choose a different scheme.292 2. group name = package category294 Under this scheme, you would have certain package categories, such as295 games, system, net,... and bash, being a system program, would possibly296 belong to the system group, so that `ls -l /bin/bash' would show something297 like this299 -rwxr-xr-x 1 bash system 1731859 Jul 4 1776 /bin/bash301 This system is nice, but probably not as useful as #1 above, unless you302 have a real use for this categorization.303 For a possible categorization see Appendix B at the end of this hint.305 3. group name = identifier for a real group of people307 Under this scheme, the group would correspond to a real group of people in308 meatspace, e.g. the group of admins responsible for the package.309 If you need something like this you'll know best what it looks like and how310 to implement it, so no further discussion of this method will be given here.313 3.4 Home Directory314 ------------------316 Although it is well possible not to have a valid home directory for package317 users or to have just one home directory shared by all package users, that318 would be a wasted opportunity. Having individual home directories for the319 package users offers a nice way to organize tarballs, patches, build scripts,320 notes and all the other per-package information that you accumulate with time.322 I suggest to use the home directory /usr/src/<package> for a package user323 called <package> with the contents detailed below. The more_control_helpers324 archive contains scripts and skeleton files that implement this suggestion.326 .bash_profile:327 You will usually want to have the same environment for all package328 users, so it is a good idea to make .bash_profile a symbolic link329 to a file in a central location. The more_control_helpers example330 uses /etc/pkgusr/bash_profile for this purpose.332 .bashrc:333 As for .bash_profile a symlink is a good idea for .bashrc. The334 more_control_helpers example uses /etc/pkgusr/bashrc as link target.335 Under normal circumstances package users are not336 (and even can not be) used for logging into the system, so there337 is little reason to distinguish between login and non-login shells338 for package users. Therefore, the example bashrc from339 more_control_helpers simply sources .bash_profile.340 This makes sure that the same environment will be used, regardless341 of whether `su <package>' or `su - <package>' is used to become342 the package user.344 .project:345 The contents of this file are printed by the commands346 `finger -l <user>' and 'pinky -l <user>' so .project is a347 good place for putting information about a package. You should348 keep the contents of the .project files for your package users349 up-to-date.351 source code:352 The package user's home directory is the perfect place for storing353 a package's source code. This includes tarballs for different354 versions, CVS checkouts, unpacked source trees for building,...356 build script(s):357 Package user installations require more careful examination of build358 and install messages than installations done as root, because of359 the package user-specific problems that can occur. Therefore it is360 unwise to simply copy'n'paste installation instructions from the361 LFS book. Build scripts allow you to use sophisticated output362 redirection for logging purposes that is impractical for direct363 entry on the command line. The build script skeleton included in364 the more_control_helpers archive demonstrates this.367 ############################################################################368 4. Common Problems369 ############################################################################371 4.1 Introduction372 ----------------374 Software installation is the crux of the package user system. Because375 installation scripts are often written under the assumption that they will be376 executed as root, they sometimes fail when executed by a package user.377 Once this hurdle is passed and a package has been installed, there's usually no378 difference to a root-installation. A few programs insist that certain379 security-sensitive files be owned by root and will not execute otherwise,380 but this is the rare exception.381 This chapter presents some more or less common problems that you will382 encounter when using package user accounts to install software, together with383 guidelines on how to deal with these issues.384 Although I've said it before I will say it again: Many of the problems you385 encounter during a package user installation are desirable features of the386 package user system. You want installation to fail rather than have387 potentially dangerous actions performed behind your back with root rights.390 4.2 General Procedure391 ---------------------393 When an installation fails it is almost always due to a "Permission denied"394 or "Operation not permitted" error while executing a command during395 `make install'. The first thing you have to do is identify the command that396 is causing the problem. Usually you will find this in the make output right397 before the error message. Once you have identified the culprit, you have to398 decide whether the action that is attempted is illegitimate, partially399 legitimate or completely legitimate. Illegitimate commands can simply be400 removed from the Makefile. The other 2 possibilities are more difficult to401 deal with. You either have to change the condition that makes the command fail402 or you have to change or sometimes remove the command and make a note if your403 change suppresses a legitimate action.405 After you've made changes to solve a certain problem, you reattempt the406 installation and solve any remaining problems until the installation407 succeeds. Once you've reached that point it is time to perform any remaining408 legitimate actions that you've had to disable, such as make certain binaries409 setuid root.411 Note that often Makefiles are generated during the configure step, sometimes412 even later in the build process. If you want to apply changes before the413 configure step you will usually have to edit files called "Makefile.in".416 4.3 Permission Changes417 ----------------------419 Some unsophisticated build systems that don't use the mkinstalldirs script to420 create installation target directories are very poorly written. Instead of421 testing whether a target directory exists, they simply attempt to create422 it with default permissions. This problem usually manifests as a line such423 as "install -d $(prefix)/bin" in the Makefile. In the common case where424 prefix=/usr this would attempt to create the /usr/bin directory. If the target425 directory already exists, as in this case, install will attempt to change its426 permissions to the default permissions (or those passed on the command line).427 Of course a package user is not allowed to change the permissions of428 /usr/bin and so the command fails with a message like429 "install: cannot change permissions of `/usr/bin': Operation not permitted"430 This is an example of a completely illegitimate command. Just remove it from431 the Makefile and everything's fine.434 4.4 Ownership Changes435 ---------------------437 The most common situation when a package wants to change the ownership of438 files during installation is when it wants to install setuid root binaries.439 A common command to do this would be something like440 "install -c -m 4755 -o root name /usr/bin/name" and the error message would441 look like this:442 "install: cannot change ownership of `name': Operation not permitted"443 The change of ownership is hidden in the "-o root" switch to install, which444 tells it to make the target file owned by root.445 The command is at least partially legitimate, because you probably want the446 binary to be installed. Whether you actually want it to be setuid root is447 a different matter. The fact that a binary is commonly installed as setuid448 root doesn't mean that you should make it so. You'll have to ask yourself if449 normal users absolutely need to execute that binary. If you think they can450 live without it you're better off not making it setuid root, because every451 setuid root binary is a potential security hole. In any case you will452 have to edit the Makefile and remove the offending switch, "-o root" in this453 case, so that the installation can succeed. Note that this will cause the454 binary to be installed setuid <package>, which of course makes no sense at all.455 If you don't intend to make the binary setuid root after the installation, it456 is best to change the "-m 4755" to "-m 755", so that it won't be installed457 setuid at all.459 TIP:460 When you make a binary setuid root after the installation, use461 `chown root /usr/bin/name' and not `chown root:root /usr/bin/name'.462 This way you can keep original group of the file (i.e. the group of the463 package user) intact. With the user name = group name scheme recommended for464 package users this makes sure that you can identify the source package of465 the binary even after making it setuid root.466 Note that as a security measure chown resets the setuid bit,467 so you will have to do `chmod u+s /usr/bin/name' after the chown.470 4.5 Write to Non-Install Directory471 ----------------------------------473 Sometimes packages want to create files or directories in non-install474 directories. 3 situations have to be distinguished in this case. The 1st475 possibility is that the target directory should be an install directory.476 An example of this is /usr/share/aclocal. This directory is not among the477 standard system directories created when building an LFS system. It will be478 created by the first package that has files to install there and will be479 owned by the corresponding package user. The next package that wants to write480 in it will fail to install. The remedy is simple. Just make the directory an481 install directory. You don't even need to be root to do it. The package user482 that owns the directory has the rights to make that change.484 The 2nd possible reason for a package wanting to write to a non-install485 directory is that the failing command is only partially legitimate, i.e. you486 do want to have installed whatever it is meant to install, but you want it in487 a different location. For example some packages install binaries that are not488 meant to be called directly. The default location for these binaries is489 sometimes called libexec and with prefix=/usr the package will attempt to490 create /usr/libexec. In cases such as this you often don't have to change491 any Makefiles. There is either a configure switch to change the directory in492 question or it is just a matter of overriding a Makefile variable as in493 `make libexecdir=/usr/lib install'.495 The 3rd possible reason for an attempt to write to a non-install directory is496 that the command in question is illegitimate, i.e. you don't want to have497 installed whatever the package wants to install. As usual with illegitimate498 commands you can edit the Makefile and just remove them. In the case of499 a whole directory whose installation you want to suppress it could be too500 much effort to remove all of the offending commands that want to install501 files there. In this case an approach similar to that from the previous502 paragraph can be more effective. Either through configure switches or503 overriding of variables you change the directory in question to something504 like <builddir>/foobar, where <builddir> is the directory in which build505 commands are run (i.e. usually the top of the unpackaged source506 tree). This will cause the package to create the unwanted directory inside507 the build tree, which doesn't cause any permission problems and has the nice508 side effect that it'll be deleted together with the build directory when you509 clean up after the build.512 4.6 Delete or Overwrite File513 ----------------------------515 In a perfect world one package should not mess with another package's files,516 but in the real world conflicts do happen occasionally. While a normal517 sysadmin installing as root won't notice this until it's too late, an admin518 employing the package user system will have to deal with conflicts right away.519 When a package tries to overwrite or delete a file or directory that is owned520 by another package the attempt will fail. It will fail even inside install521 directories because of the sticky bit.522 Although sometimes difficult to implement, the solution to such a conflict is523 easy to describe. You need to either remove (or rename) the old file or524 directory before installing, or suppress the installation of the new file or525 directory. The installation of individual binaries is sometimes easy to526 prevent. If you find a line such as "PROGRAMS=foo bar fubar barfu" in the527 Makefile and "foo" is the name of the conflicting binary, just try removing528 it from that list. That may be sufficient to prevent it from being installed.531 4.7 /sbin/ldconfig532 ------------------534 Packages that install libraries sometimes run /sbin/ldconfig as part of their535 installation so that the dynamic libraries are properly registered on the536 system. Because a package user is not allowed to overwrite /etc/ld.so.cache537 ldconfig fails. This failure is commonly ignored in Makefiles, but you should538 take note of it anyway, because you need to run ldconfig as root after539 the installation. Alternatively, the more_control_helpers contain a wrapper540 program that calls /sbin/ldconfig and can be made setuid root.543 4.8 What Commands to Run as a Package User544 ------------------------------------------546 A common problem that new users of this hint have is to decide which commands547 to run as a package user and which commands to run as root. The general rule548 is that the only commands to run as a package user are those for building,549 installing, removing and modifying the files that belong to *that* package550 user's package. Everything else should be run as root as usual.551 Some things you CAN/SHOULD NOT DO as a package user include553 - starting daemons554 - running udevstart555 - stripping /lib/*558 ############################################################################559 5. The more_control_helpers Archive560 ############################################################################562 5.1 Overview563 ------------565 The more_control_helpers archive contains files to help you with building and566 maintaining a system that uses the package user method. One thing that the567 more_control_helpers archive contains are some LFS-specific temporary files568 that are only needed for the building of your LFS system and will not remain569 installed in a permanent location. Then there are the previously mentioned570 example files that demonstrate the suggested use of the package user home571 directories discussed earlier. Another group of files contained in the archive572 is a set of scripts that help with package management aspects, such as573 creating new package users and checking which files a particular package has574 installed. Finally the more_control_helpers archive contains wrapper scripts575 for some commands that handle many of the common problems discussed in the576 previous chapter and make package user installations a lot easier.579 5.2 The Wrappers580 ----------------582 The previous chapter discussed some common problems encountered during583 package user builds and how to solve them. The solution to an installation584 failure usually requires editing of one or more Makefiles. Making such changes585 manually is annoying, even if it happens only occasionally, and whenever you586 reinstall a package you have to make the changes again. Sed scripts and patches587 can help with the latter problem, but they still have to be custom fitted to588 every package that needs them. There is a better solution, though. While there589 exist countless ways to install files, only very few are commonly used by590 packages. The 5 commands mkdir, chgrp, chown, chmod and install are responsible591 for most of the problems that arise during an LFS installation. This592 prompted me to write wrapper scripts for these 5 commands that recognize593 certain problematic patterns and deal with them automatically.595 The instructions given in this hint in the LFS-specific part will instruct you596 to install these wrappers in /usr/lib/pkgusr. If you do that and make sure597 that this directory is the first entry in the PATH of every package user, then598 they will save you a lot of time and effort in dealing with recurring issues.599 Note that if you want to choose a directory other than /usr/lib/pkgusr for600 the wrappers, you need to be careful. Some configure scripts ignore certain601 locations. A subdirectory of /etc would not work, for instance, because /etc602 is one of these locations.604 It is important that you understand the limitations of the wrapper scripts.605 They can fix some problems without user intervention, such as turning606 newly created directories in /usr/share/locale into install directories.607 But other problems by their very nature require manual intervention. When a608 program tries to install a setuid root binary, for instance, the wrapper609 scripts will suppress the attempt to change ownership of an installed file to610 root. While that allows `make install' to complete without error, it is only611 a partial solution. The wrapper scripts can not (and should not) take away612 your responsibility for deciding whether the program in question should be613 setuid root and to make it so, if necessary. To account for this, the614 wrapper scripts will output warning lines to standard error that start with615 "***" whenever they encounter a situation that needs to be reviewed.616 Following the "***" in the message will be the original command that the617 installation attempted to perform.618 You *must* check these "***" lines, examine the affected files or directories619 and take appropriate action. Because of this it is imperative that you log620 the messages output during a package installation and check these logs621 religiously. The `build' script contained in the more_control_helpers archive622 demonstrates some useful output redirection tricks to be used for this purpose.623 The following 3 examples shall illustrate what kind of things you will have to624 look for:626 Example 1: "*** install -c rsh -o root -m 4775 /usr/bin/rsh"627 This message is output by the install wrapper during the installation of628 inetutils. The package wants to install the rsh binary setuid root. The629 install wrapper removes the "-o root" and changes the "-m 4775" to630 "-m 755" before passing the command on to the real install program.631 The important thing here is the "-m 4xxx", because this wants to set the632 setuid bit. Some install scripts throw in a "-o root" for good measure633 when installing an otherwise normal binary. In that case it's enough that634 the install wrapper strips out the "-o root" and you don't have to take635 further action. But when, as in the case of inetutils, the permissions636 indicate an attempt to make a binary setuid or setgid, then you will have to637 investigate. You need to decide if you want rsh to be setuid root and638 if you decide you do, you need to become root and issue commands like this:640 chown root /usr/bin/rsh641 chmod u+s /usr/bin/rsh643 TIP:644 Be conservative with making binaries setuid. If you're unsure whether you645 will ever use a program (as non-root), you probably don't want it to be646 setuid root. Keep in mind that you can always make the change later when647 you need it. When you apply this reasoning to rsh, for instance, you'll648 probably end up not making it setuid root.651 Example 2: "*** chgrp tty /usr/bin/write"652 This is output by the chgrp wrapper during the util-linux installation.653 The util-linux package wants to install the write program as setgid tty,654 so that it is allowed to access other users' terminals. The chgrp wrapper655 prevents the changing of the group and the chmod wrapper prevents the656 setting of the setgid bit. You need to decide if you want the657 program to be setgid and if you decide in favor of this, do as root659 chgrp tty /usr/bin/write660 chmod g+s /usr/bin/write663 Example 3: "*** install -d -m 755 /sbin"664 This is also from the util-linux installation. Util-linux, for no good665 reason, tries to recreate the /sbin directory. The install wrapper666 prevents this and you don't have to take any further action.669 5.3 add_package_user/install_package670 ------------------------------------672 Whenever you install a new package on your system, you first have to create673 a new user account, possibly create a new group and if you follow the advice674 from this hint about making productive use of a package user's home directory,675 you will have to set up that one, too. If you were to do all of this manually,676 it would be a lot of work. The add_package_user and install_package scripts677 in the more_control_helpers archive were written to automate this.679 The install_package script is the one you will normally use to prepare for680 installing a new package. It takes 3 parameters: the description of the681 package, the name of the package user account to create and the name of the682 package user's primary group. So if you use the user=group scheme recommended683 by this hint and are as creative with your package descriptions as I am, then684 the command you'll use to prepare for installing package "foo" will be686 install_package foo foo foo688 This command does 2 things. First it calls the add_package_user script with689 the provided name, group and description plus sensible default values for690 add_package_user's other parameters. Then, after add_package_user has created691 the package user account, install_package automatically uses the su-command692 to switch to the newly created account. If the default .bashrc and693 .bash_profile scripts you use for package users contain the command "cd" as do694 the examples in the more_control_helpers archive, you will be put right into695 your package user's home directory so that you can start installing right away.697 TIP:698 The install_package script can be called with a single argument that will699 be used as user name, group name and description. So instead of the above700 command a simple `install_package foo' would have sufficed.702 The add_package_user script is responsible for the actual work of creating703 a new package user account. Given a name, a group name and a description, it704 will create a new user account with the provided primary group and the install705 group as supplementary group. The groups will be created if necessary.706 add_package_user takes several arguments that determine the numeric ranges from707 which it will pick the new user's UID and the GIDs for groups it needs to708 create. add_package_user does not only create the package user account. It709 will set up a home directory for it, too. You can either specify the directory710 or go with the default, which is /usr/src/<name>, where <name> is the name711 provided for the new account. If the home directory already exists, its712 ownership and that of any existing contents will be changed to the new user.713 If it doesn't exist, it will be created.715 The contents of /etc/pkgusr/skel-package will be copied into the new package716 user's home directory (without overwriting pre-existing files).717 The more_control_helpers archive contains an example of a useful skel-package718 directory. Note that symlinks are copied as symlinks, so skel-package is the719 perfect place to put .bashrc and .bash_profile symlinks to a central location720 that will ensure that all package user accounts have the same environment.721 This is especially useful to make sure that all package users have the722 wrappers directory in their PATH.725 5.4 forall_direntries_from726 --------------------------728 The forall_direntries_from script is a very useful tool for common package729 management tasks. It can roughly be described as a shortcut for730 "find / -user <name> -or -group <name> <commands>", where <name> is the731 first parameter to forall_direntries_from and <commands> are the remaining732 parameters. However, forall_direntries_from takes care of making sure that733 only relevant filesystems are scanned and shields you from certain unpleasant734 surprises such as "Oops, I forgot that -depth negates -prune and have735 accidentally wiped out my home directory." or "Oops, I forgot to -prune /proc736 and now I'm getting parity errors on my SCSI bus.".738 IMPORTANT NOTE: By default the forall_direntries_from script will only scan739 the / filesystem and will not traverse other filesystems. If you have740 relevant directories that need to be scanned on other filesystems, you will741 need to edit the script and add the respective mount point(s) to the742 fs_to_scan list at the beginning of the script. The most likely candidate for743 addition is "/usr".745 Application examples:747 Example 1: Create a tar.gz archive of all files that belong to <package>, e.g.748 for installing <package> on another machine without having to749 recompile it there.751 forall_direntries_from <package> -fprint0 /tmp/files.lst752 tar --null -P -czf /tmp/archive.tar.gz --files-from=/tmp/files.lst755 Example 2: Print out all setuid root binaries installed by <package>.756 (This only works if you use the user=group scheme.)758 forall_direntries_from <package> -perm +u+s -print761 Example 3: List all binaries in /bin and /usr/bin belonging to "me" (i.e. the762 package user executing the command) in alphabetical order.764 forall_direntries_from $(whoami) -path "*/bin/*" -printf "%f\n" | sort767 Example 4: Uninstall <package>.769 See following section about the uninstall_package script.772 5.5 uninstall_package773 ---------------------775 The uninstall_package script is basically a forall_direntries_from776 application example in script form. The command `uninstall_package foo'777 prints out the forall_direntries_from call that you have to use to delete778 all the files of package "foo" (except for those in directories that779 forall_direntries_from is instructed not to scan) together with some780 explanations. So in order to delete the files from package foo, you would781 execute `uninstall_package foo' and then copy'n'paste the command it prints782 to the command line. As a safeguard the forall_direntries_from call has an783 "echo" in front of the "rm" and "rmdir" calls, so if you execute it, the files784 will not actually be deleted unless you remove both instances of "echo".785 It is recommended that you execute the command once with the echos and check786 the output to make sure that only the files you intend to be deleted are in787 the list. After you've confirmed that, you can use the shell's history to788 recall the command, edit out the instances of "echo" and remove the files789 for real.792 5.6 list_suspicious_files/list_suspicious_files_from793 ----------------------------------------------------795 list_suspicious_files looks for filesystem entries that are out of the ordinary796 in some way and prints a categorized list of them. Things that qualify as797 suspicious include setuid and setgid binaries, world-writable files, symlinks798 that are possibly broken, hard links, install directories with unusual799 permissions and other stuff. You should run this script after you've finished800 your new LFS system and in regular intervals after that. Investigate the801 listing closely.803 TIP:804 When you check the list of setuid and setgid files, don't forget to805 look at the actual user or group ownership of the file. It's easy to forget806 that, especially in the setuid case, because we often equate setuid with807 setuid root since setuid is seldom used with other user accounts.809 list_suspicious_files_from takes a user or group name or a UID/GID as an810 argument and reports suspicious entries only when they are owned by the given811 user or group. Usually you would not call this script directly but instead812 use list_package (described in the next section), whose output includes that813 from list_suspicious_files_from.815 IMPORTANT NOTE: By default the list_suspicious_files script will only scan816 the / filesystem and will not traverse other filesystems. If you have817 relevant directories that need to be scanned on other filesystems, you will818 need to edit the script and add the respective mount point(s) to the819 fs_to_scan list at the beginning of the script. The most likely candidate for820 addition is "/usr".823 5.7 list_package824 ----------------826 list_package tells you everything about a package's installed files. In827 general you will want to execute something like829 list_package $(whoami) >pkg.lst831 right after installing a package and you can forget about the chronically832 inaccurate content listings in the (B)LFS book.833 The following (shortened) output for util-linux speaks for itself:835 PS1> list_package util-linux837 EXECUTABLES (in */bin or */sbin)838 agetty, arch, blockdev, cal, cfdisk, [...] vidmode(->rdev), whereis, write840 EXECUTABLES WITH NO MANPAGE (in */bin or */sbin)841 fsck.cramfs, mkfs.cramfs843 MANPAGE SUMMARIES OF EXECUTABLES (in */bin or */sbin)844 agetty: alternative Linux getty845 arch: print machine architecture846 blockdev: call block device ioctls from the command line847 cal: displays a calendar848 cfdisk: Curses based disk partition table manipulator for Linux849 chkdupexe: find duplicate executables850 col: filter reverse line feeds from input851 [...]852 swapon: enable/disable devices and files for paging and swapping853 tailf: follow the growth of a log file854 tunelp: set various parameters for the lp device855 ul: do underlining856 umount: unmount file systems857 vidmode: query/set image root device, RAM disk size, or video mode858 whereis: locate the binary, source, and manual page files for a command859 write: send a message to another user861 EXTRA MANPAGES862 /usr/share/man/man5/fstab.5863 /usr/share/man/man5/nfs.5864 /usr/share/man/man8/sln.8866 EXTRA EXECUTABLES (not in */bin or */sbin)867 /usr/share/misc/getopt/getopt-parse.bash868 /usr/share/misc/getopt/getopt-parse.tcsh869 /usr/share/misc/getopt/getopt-test.bash870 /usr/share/misc/getopt/getopt-test.tcsh872 ALL FILES873 /etc/fdprm874 /sbin/agetty875 /sbin/blockdev876 /sbin/cfdisk877 /sbin/ctrlaltdel878 /sbin/elvtune879 /sbin/fdisk880 /sbin/fsck.cramfs881 /sbin/fsck.minix882 /sbin/hwclock883 /sbin/losetup884 /sbin/mkfs885 /sbin/mkfs.bfs886 [...]887 /usr/share/man/man8/rootflags.8888 /usr/share/man/man8/setfdprm.8889 /usr/share/man/man8/setsid.8890 /usr/share/man/man8/sfdisk.8891 /usr/share/man/man8/sln.8892 /usr/share/man/man8/swapoff.8893 /usr/share/man/man8/swapon.8894 /usr/share/man/man8/tunelp.8895 /usr/share/man/man8/umount.8896 /usr/share/man/man8/vidmode.8897 /usr/share/misc/getopt898 /usr/share/misc/getopt/getopt-parse.bash899 /usr/share/misc/getopt/getopt-parse.tcsh900 /usr/share/misc/getopt/getopt-test.bash901 /usr/share/misc/getopt/getopt-test.tcsh903 SETUID FILES904 -rwsr-xr-x "/usr/bin/mount" root:util-linux905 -rwsr-xr-x "/usr/bin/umount" root:util-linux907 SETGID FILES908 -rwxr-sr-x "/usr/bin/write" util-linux:tty910 FILES WITH UNUSUAL PERMISSIONS911 -rwsr-xr-x "/usr/bin/mount" root:util-linux912 -rwsr-xr-x "/usr/bin/umount" root:util-linux913 -rwxr-sr-x "/usr/bin/write" util-linux:tty916 Note: list_package works regardless of the prefix you've installed the package917 with, so you can for instance configure with --prefix=/opt/package and918 list_package will work just fine (provided that /opt is on a919 filesystem configured to be scanned by forall_direntries_from and920 list_suspicious_files).922 Note: list_package only considers manpages actually owned by the package to923 list. It will not consider manpages installed by another package. This924 means that you may see executables identified as not having a manpage925 although they do have one courtesy of another package926 (usually man-pages).929 5.8 grep_all_regular_files_for930 ------------------------------932 This script is not really related to the package user system, but because of933 its similarity to the other scripts I've included it anyway. The sole purpose934 of this script is to identify files that store references to the build935 environment, specifically the /tools directory. Such references may point out936 problems, since the /tools directory is supposed to be transient.937 Don't forget that results for unstripped binaries and libraries are not938 reliable, because debugging information often includes references to the939 build environment. These do not cause trouble (unless you're trying to debug940 the objects in question after deleting /tools).942 IMPORTANT NOTE: By default the grep_all_regular_files_for script will only scan943 the / filesystem and will not traverse other filesystems. If you have944 relevant directories that need to be scanned on other filesystems, you will945 need to edit the script and add the respective mount point(s) to the946 fs_to_scan list at the beginning of the script. The most likely candidate for947 addition is "/usr".950 5.9 The etc Directory951 ---------------------953 If you follow the instructions provided in the LFS-specific part of this hint,954 the contents of the etc directory will be installed in /etc/pkgusr. The955 directory contains a bashrc and bash_profile for package users that takes956 care of package user specific details such as putting the wrappers directory957 at the beginning of the PATH and calling cd, so that `su <package>' will958 put you right into the package user's home directory. Also contained in the959 etc directory is a skel-package directory as used by960 install_package/add_package_user to populate the home directories of newly961 created package users.964 5.10 ldconfig.c965 --------------------967 A lot of packages contain libraries. Having to manually call /sbin/ldconfig968 as root after installing these packages can become annoying. It would be969 much easier if one could grant package users permission to use /sbin/ldconfig.970 Making ldconfig setuid root would be a simple and effective solution, but971 there are some pitfalls. First of all it is imperative that ordinary users972 be prohibited from executing ldconfig with elevated privileges. Otherwise973 an ordinary user can overwrite and possibly read arbitrary files on the974 system. This can be prevented by making ldconfig owned by group install and975 removing the o+x bit from the file mode. While this setup is no less secure976 than running `make install' as root, one reason why we're using package users977 is because we don't feel safe doing that. To protect against the (admittedly978 very theoretical) danger of a malicious package user, the more_control_helpers979 provide ldconfig.c. The only thing this program does is to call980 `/sbin/ldconfig -v' with an empty environment. Because it doesn't evaluate981 any user input and doesn't pass any user-provided data to ldconfig, it can982 safely be made setuid root.985 5.11 Temporary Files986 --------------------988 3 files in the more_control_helpers archive are only used during the989 installation of the base LFS system and are not installed permanently.990 The first of them is the installdirs.lst file that contains a list of991 directories that should be install directories.992 The second file is sbin/useradd, which is a very primitive shell script that993 adds a new entry to /etc/passwd. It allows us to add package users before994 we have installed shadow, which provides a real useradd.995 Finally there is groupadd, which is like useradd, only for /etc/group.996 Both scripts, useradd as well as groupadd, do very little error checking and997 only support the syntax needed by install_package/add_package_user. So don't998 try anything funky with them.1001 ------------------------ PART 2: LFS Specifics ------------------------------1004 #############################################################################1005 6. Pre-Chroot Phase (Chapter 5)1006 #############################################################################1008 Build Chapter 5 explained by the LFS book with the following changes:1010 coreutils:1011 After running `make install' for the coreutils1012 package, issue the following command (still from within the coreutils1013 build directory):1015 cp src/su /tools/bin1017 This installs the su binary. Coreutils doesn't install su when working as1018 non-root (which we do in Chapter 5), because su needs to be setuid root for1019 normal operation and a non-root user cannot install setuid root binaries.1020 But for our purposes (i.e. su'ing from root to a package user) a non-setuid1021 su is enough, so we just copy coreutils' su to /tools/bin without making it1022 setuid root.1024 more_control_helpers:1025 When you have reached the end of Chapter 5, before you begin with Chapter 61026 you will need to install the helper scripts in the /tools directory so that1027 they are available once you've entered the chroot environment. Use the1028 following commands to install the more_control_helpers in /tools:1030 cd /tools &&1031 tar xjf /path/to/more_control_helpers.tar.bz2 &&1032 cd more_control_helpers &&1033 cp ./sbin/* /tools/bin1035 Note that the target directory is "/tools/bin" in the cp command and1036 *not* "/tools/sbin", although the latter location would be more appropriate.1037 The reason for this is simply that the LFS instructions do not add1038 "/tools/sbin" to the PATH (and neither do the instructions in this hint).1041 #############################################################################1042 7. Chroot Phase (Chapter 6)1043 #############################################################################1045 7.1 Preparations1046 ----------------1048 Enter the chroot environment and follow the instructions from the book up to1049 but *not* including the installation of the first package (which at the time of1050 this writing is linux-libc-headers). Now install the more_control_helpers1051 files in their proper locations on the new LFS system:1053 cp -a /tools/more_control_helpers/etc /etc/pkgusr &&1054 chown -R 0:0 /etc/pkgusr &&1055 cp -a /tools/more_control_helpers/lib /usr/lib/pkgusr &&1056 chown -R 0:0 /usr/lib/pkgusr &&1057 cp /tools/more_control_helpers/bin/* /usr/bin &&1058 cp /tools/more_control_helpers/sbin/* /usr/sbin &&1059 rm /usr/sbin/{useradd,groupadd}1061 Note that the useradd and groupadd scripts are not installed on the new LFS1062 system. These scripts are just temporary workarounds we will use as long as1063 the real useradd and groupadd are not available. Therefore they should only1064 be in /tools/bin.1066 ATTENTION! If you decide to use a different directory than /usr/lib/pkgusr1067 for the wrappers, you have to be careful, because at least the glibc1068 configure script ignores certain directories when looking for programs. The1069 list of ignored directories for glibc includes, among others, everything that1070 starts with "/etc", "/usr/etc" and "/sbin". Wrappers put into a directory that1071 matches any of these patterns would be ineffective.1073 Now it's time to create the install group:1075 groupadd -g 9999 install1077 The GID 9999 has been chosen because the default range used by1078 add_package_user for package user GIDs starts at 10000. Choose whatever number1079 you like.1081 Once the install group has been created you have to turn all the directories1082 that packages will install files in into install directories. To make this1083 easier I have compiled a list of install directories that can be found in1084 the file /tools/more_control_helpers/installdirs.lst. The following command1085 uses this list to assign the necessary directories to the install group.1086 Note that you will get several error messages because of non-existent1087 directories. This is because the list contains some directories not created1088 by LFS.1090 chown 0:9999 $(cat /tools/more_control_helpers/installdirs.lst)1092 To be usable by package users, the directories will have to be group-writable1093 and should be sticky as has been explained in the beginning of this hint.1094 The following command sets the permissions appropriately.1095 You will get the same error messages as for the previous command.1097 chmod ug=rwx,o=rxt $(cat /tools/more_control_helpers/installdirs.lst)1100 7.2 Walkthrough: Installing linux-libc-headers1101 ----------------------------------------------1103 At this point everything has been set up for creating the first package1104 user. At the time of this writing the first package installed in the LFS1105 book is Linux-Libc-Headers, so this package will serve as an example for how1106 things are done. The command1108 install_package 'Linux Headers' linux-libc-headers linux-libc-headers1110 will create a package user with user and group name linux-libc-headers.1111 If you don't want to use the user=group scheme, change the last argument to1112 the desired group name. The description is arbitrary but needs to meet the1113 requirements for the description field of an /etc/passwd entry.1115 TIP:1116 Remember that you can call install_package with just one argument, if you1117 want user name, group name and description to be the same.1119 The directory /usr/src/linux-libc-headers will be set up as the home directory1120 for the package user, automatically populated with the contents of1121 /etc/pkgusr/skel-package. The install_package command also issues the command1122 `su - linux-libc-headers' to assume the identity of the newly created package1123 user. If you're using the bashrc and bash_profile scripts from the1124 more_control_helpers archive, you will be put straight into the directory1125 /usr/src/linux-libc-headers and your prompt will look like this1127 package linux-libc-headers:/usr/src/linux-libc-headers>1129 to show you that you're working as package user linux-libc-headers and1130 that your current working directory is /usr/src/linux-libc-headers.1132 Use the command1134 echo $PATH1136 to verify that your PATH starts with "/usr/lib/pkgusr", the directory that1137 contains the wrappers, and ends with "/tools/bin".1139 Now everything is prepared for installing the package according to the1140 instructions in the LFS book. Note that at the time of this writing the1141 LFS book tells you to execute a chown command to make sure that the headers1142 are owned by root. This is just because the packager has made a very common1143 mistake when creating the tarball for the headers: He has archived the files1144 with a non-root user/group assignment. When unpacking such a tarball as root,1145 the files end up being owned by some weird user/group combination, which may1146 open a security hole. When you're working as a package user this can not1147 happen and you don't want to chown the headers to root:root, because that1148 would defeat the whole point of installing the headers with a package user.1149 This is one of the small points on which you will have to deviate from the1150 standard LFS instructions when using package users. More package user related1151 issues with the current LFS book can be found in the next section.1153 After you've installed the headers, simply issue the command1155 exit1157 to become root again. Now would be a good time to think about useful1158 customizations for /etc/pkgusr/{bash_profile,bashrc} and/or1159 /etc/pkgusr/skel-package, if you've not already customized them.1160 Once you're satisfied with your setup, install the rest of the packages.1161 The following section will help you with some problems that you will run into.1164 7.3 Known Issues with LFS Packages1165 ----------------------------------1167 This section has details on the package user related problems you will face1168 when building your LFS system. You should copy the information from this1169 section to the INSTALL NOTES of the relevant .project files for the packages1170 concerned, together with any of your own notes.1172 NOTE: If you're building by an LFS book later than 6.2 it is recommended that1173 you read this complete chapter before you start building any packages.1174 If your LFS version is 6.2 then it's fine to read this section package1175 by package as you progress with your build.1178 linux-libc-headers:1179 At the time of this writing the LFS book tells you to execute a chown1180 command to make sure that the headers are owned by root. This is just1181 because the packager has made a very common mistake when creating the1182 tarball for the headers: He has archived the files with a non-root1183 user/group assignment. When unpacking such a tarball as root, the files1184 end up being owned by some weird user/group combination, which may open1185 a security hole. When you're working as a package user this can not happen1186 and you don't want to chown the headers to root:root, because that would1187 defeat the whole point of installing the headers with a package user.1189 There used to be another packaging error in the linux-libc-headers.1190 Version 2.6.12.0 (current as of this writing) doesn't have it anymore,1191 but older versions used to contain files with permissions set incorrectly.1192 All headers are supposed to be world-readable, but they weren't. More about1193 this later in the glibc notes.1196 man-pages:1197 If the name you use for the man-pages package user is not exactly1198 "man-pages", then you will have to change the variable "manpagesowner"1199 right at the beginning of the wrapper script `install'.1201 Recent versions of man-pages contain POSIX manpages that the package1202 tries to install in /usr/share/man/man{0,1,3}p. There's also a manpage1203 that man-pages wants to install to /usr/share/man/man9.1204 As /usr/share/man is1205 not an install directory and the LFS book does not have instructions to1206 create these directories at the time of this writing, the installation1207 will fail and the respective man-pages will not be installed.1208 Possible remedies:1209 1. Make /usr/share/man an install directory.1210 Consequence: All Packages will be able to create new subdirectories1211 in /usr/share/man. I find this undesirable because there are packages1212 that create directories for manpages in foreign languages that I1213 don't want. YMMV.1214 2. Ignore the problem and live without the POSIX manpages. Unless1215 you are a developer (including script writer) who is interested1216 in writing portable programs/scripts this is a good solution.1217 3. Create the directories /usr/share/man/man{0,1,3}p and man9 as root1218 prior to installing man-pages. You'll have to either chown them1219 to the man-pages package user or make them install directories.1220 This is my preferred solution.1223 glibc:1224 It is kind of unfortunate that the packaging error of libc-linux-headers1225 concerning the permissions doesn't exist in the current version. It1226 provided for a great learning experience. I've kept the following section1227 in the hint for this reason even though it doesn't apply anymore. Please1228 take the time to read it.1230 --------------------- old stuff start ----------------------------------------1231 Because of the error, the headers in /tools/include1232 are not world-readable. Unfortunately the LFS book (as of this writing)1233 does not correct this in Chapter 5 like it does in Chapter 6. For a1234 standard LFS build this is no problem, because glibc is built as root and1235 root can access everything regardless of permissions.1236 The glibc package user, however, does not have permission to access1237 these headers. This will cause several configure tests to fail, because1238 the respective test programs can not be compiled.1239 The end result is the error message "/lib/cpp fails sanity check", which1240 is completely nonsensical as we don't have a /lib/cpp.1242 This is the perfect opportunity to introduce rule #1 of error diagnostics:1244 NEVER TRUST DIAGNOSTIC MESSAGES !1246 There are 2 kinds of diagnostic messages:1248 1. Those that are unnecessary, because once you see which component has1249 failed, the source of the problem is obvious.1250 2. Those that grossly misdiagnose the source of the problem and lead1251 you to draw the wrong conclusions.1253 No, there is no other kind. Trust me ;-)1254 In this case, /lib/cpp has nothing to do with the problem. It doesn't1255 exist and that's fine. The message just wants to trick you into doing1256 something stupid such as create a symlink /lib/cpp -> /tools/bin/cpp.1257 But that would be totally wrong. Before you jump to any premature1258 conclusions you should always try to get as much *low-level* information1259 as you can. Diagnostic messages are *high-level* information. They1260 represent a filtered view of the problem, which is usually of little help.1261 Fortunately the message (the complete one, not the part quoted above) also1262 points at the source for the necessary low-level information. In this1263 case that is the file config.log (not to be confused with configure.log,1264 the file created by the build script included in the more_control_helpers1265 archive).1266 config.log is created by all autoconf-created configures (not just that1267 of glibc) and it contains, among other things, the test programs used by1268 configure and messages output while building and running them. Whenever a1269 configure script fails or gives weird results, check config.log. And1270 always remember rule #2 of error diagnostics1272 ALWAYS START AT THE FIRST ERROR1274 This seems pretty obvious, but nevertheless people commonly do the exact1275 opposite. It's just too tempting to start at the point of the final1276 failure and try to work backwards. In this case many people would open1277 config.log and scroll to the point of the failed /lib/cpp sanity check.1278 After all, that's what caused configure to abort and so that's what needs1279 to be fixed, right? WRONG! Someone who takes this approach just sees the1280 error message "/lib/cpp: No such file or directory" and is even more1281 convinced that a missing /lib/cpp symlink (or program) is the problem.1283 The correct way to approach such a problem is to start at the beginning1284 of config.log, to scroll down to first error message and to check if it1285 is an issue that needs to be fixed (error messages in config.log are1286 not always signs for a problem). If the issue needs to be fixed, then1287 it needs to be fixed first, because all later errors could be rooted in1288 this issue (even if, no, *especially* if you don't believe this is the1289 case).1290 If we apply this advice to the problem at hand, we quickly get to the first1291 serious error in config.log:1293 "/tools/include/linux/limits.h: Permission denied"1295 A quick check with ls reveals that indeed the directory with the linux1296 headers is not world-readable, which is obviously wrong. The fix is1297 easy. Just make (as root) the header directories /tools/include/{linux,asm}1298 world-readable with commands similar to those the LFS book presents1299 in Chapter 6 for the installation of linux-libc-headers.1300 Once this change has been made, glibc's configure succeeds.1301 --------------------- old stuff end -----------------------------------------1303 TIP:1304 Even when configure completes successfully, you should still check the1305 output carefully to see if there is anything odd. E.g. if you're using1306 the wrappers, you should check that configure outputs the line1308 checking for a BSD-compatible install... /usr/lib/pkgusr/install -c1310 If configure detects a different install, such as /tools/bin/install,1311 something is wrong. Maybe there's a typo in the PATH for the package1312 user, or you've put the wrappers into a directory that is ignored by1313 configure.1316 With the wrappers the glibc build and install should work smoothly.1317 The wrapper script for install makes sure that the /usr/share/locale/*1318 directories become install directories so that other programs can install1319 their localized messages.1320 One thing that the wrappers do not take care of,1321 however, is the file /usr/share/info/dir. Because in the current LFS build1322 order glibc is the first package that installs info files, dir is owned by1323 and only writable by glibc. In order to allow other packages to install1324 info pages, execute the following commands as root:1326 chown root:install /usr/share/info/dir &&1327 chmod ug=rw,o=r /usr/share/info/dir1329 NOTE:1330 glibc wants to install the program pt_chown as setuid root. If you install1331 as a package user, the program will get installed but not given root1332 privileges (because of the install wrapper).1333 The following info is from the glibc docs:1335 One auxiliary program, `/usr/libexec/pt_chown', is installed setuid1336 `root'. This program is invoked by the `grantpt' function; it sets the1337 permissions on a pseudoterminal so it can be used by the calling1338 process. This means programs like `xterm' and `screen' do not have to1339 be setuid to get a pty. (There may be other reasons why they need1340 privileges.) If you are using a 2.1 or newer Linux kernel with the1341 `devptsfs' or `devfs' filesystems providing pty slaves, you don't need1342 this program; otherwise you do. The source for `pt_chown' is in1343 `login/programs/pt_chown.c'.1345 So unless you're building a system that does not use devpts (which would1346 be quite unusual), this does not need to concern you.1348 TIP:1349 In case you were wondering if you should create /etc/nsswitch.conf and1350 /etc/ld.so.conf as root or glibc, I recommend to assign all files that1351 you manually create or manually edit to the root account. That way you can1352 distinguish between those files that can be regenerated automatically and1353 those that can not. Assigning even automatically generated files to1354 root once you make the first manual edit, ensures that a later1355 reinstallation of a package won't silently do away with your manual tweaks.1357 ldconfig:1358 Now that glibc has installed /sbin/ldconfig you can activate the ldconfig1359 wrapper if you want to. Perform the following steps as root1360 AFTER re-adjusting the toolchain,1361 just before starting with binutils:1363 cd /usr/lib/pkgusr1364 gcc -O2 -W -Wall -o ldconfig ldconfig.c1365 chown root:install ldconfig1366 chmod u=rwxs,g=rxs,o= ldconfig1368 These instructions make the ldconfig wrapper setuid root and setgid install1369 and prevent non-root users not in the install group from executing it.1370 The setuid root is required so that it can replace /etc/ld.so.cache.1371 The setgid install is not strictly required, but without it1372 /etc/ld.so.cache will end up with the group of the last package user that1373 touched it. If you use the user name=group name scheme this will cause the1374 more_control_helpers scripts to believe that /etc/ld.so.cache belongs to1375 the package in question which can be confusing.1377 binutils:1378 Have you make /usr/share/info/dir group-writable as explained above in1379 the glibc notes? If you've missed that part, go back and do it now.1380 The installation of binutils should complete without problems.1381 It does however cause minor conflicts with autoconf (see later).1383 NOTE:1384 At the time of this writing the version of bash used in the LFS book has1385 a bug that causes the list_package script to spit out errors and to list1386 all manpages of binutils (and other packages) as Broken. This bug is1387 already fixed by the bash patch used by the book but the patch is not1388 applied in chapter 5. Since the manpage summary functionality of1389 list_package requires man which is not installed until after bash is1390 rebuilt, this doesn't really matter, because while patching the1391 chapter 5 bash would get rid of the error messages, it wouldn't result1392 in usable manpage summaries.1395 gcc:1396 Because the /usr/lib/libgcc_s.so* symlinks created at the beginning of1397 Chapter 6 is owned by root, gcc's installation cannot remove it.1398 So you will have to remove it as root before `make install'.1399 Alternatively use1401 chown -h gcc: /usr/lib/libgcc*1403 to change ownership of the files in question after creating the gcc1404 package user. Note the -h option which has to be used to change1405 ownership of the symlinks themselves rather than their target files.1407 db:1408 It should be obvious that you don't want to change the ownership of the1409 installed files.1412 coreutils:1413 Because the /bin/cat, /bin/pwd and /bin/stty symlinks are owned by root,1414 coreutils' installation cannot remove them. So you will have to remove1415 them manually before `make install'. Alternatively use the command1417 chown -h coreutils: /bin/{cat,pwd,stty}1419 after creating the coreutils package user. Note the -h switch that makes1420 chown change the ownership of the symlinks themselves rather than their1421 target files.1423 The chapter 6 instructions move the coreutils binaries to /bin, including1424 the mv binary itself. You need to make sure that hashing is turned off1425 for this to work. The LFS book does this by putting `set +h' into the1426 LFS user's .bashrc. If you're following this hint, you're likely using1427 build scripts, so you need to put this command into the build script1428 before the mv commands.1430 NOTE:1431 The man-pages package has already installed manpages for the binaries1432 from coreutils. The install wrapper will prevent coreutils from overwriting1433 those. This is done because the manpages from the man-pages package are1434 of superior quality (although not necessarily uptodate).1435 It also prevents errors during `make install' that1436 would otherwise occur because the coreutils package user cannot overwrite1437 manpages owned by another user.1438 If you don't like the above behaviour and would rather have the original1439 package manpages (because they are uptodate), you can set the variable1440 manpagesowner at the beginning of the install wrapper to a string that1441 doesn't correspond to a package user name (it must not be empty, though!).1442 If you do this, you will have to resolve manpage conflicts in another way.1443 The easiest way to handle this is probably to not install the man-pages1444 package at the beginning of Chapter 6 but at the end, after all the other1445 packages have already installed their manpages. Then you need only deal1446 with the conflicts once, when installing man-pages.1449 ncurses:1450 The installation of ncurses (like that of other packages that include1451 libraries) wants to run /sbin/ldconfig to update /etc/ld.so.cache.1452 This fails because the package user doesn't have permission to replace1453 /etc/ld.so.cache.1454 Making /etc/ld.so.cache group-writable by the install group doesn't help,1455 because the permissions would be reset on the next call to /sbin/ldconfig.1456 This error will usually not abort the installation and you can just1457 run /sbin/ldconfig manually as root afterwards.1458 Alternatively you can use the ldconfig wrapper as described earlier.1461 aclocal directory:1462 At the time of this writing the directory /usr/share/aclocal is1463 created during the bison installation. This directory contains1464 macros for autoconf. Other packages want to install1465 files into this directory, so you should make it writable by the install1466 group and sticky.1469 perl:1470 Before you do `make install', you will have to1471 `chown -h perl: /usr/bin/perl' so that the perl package user is allowed to1472 remove the /usr/bin/perl symlink.1474 If you will install add-on packages for perl as their own package users1475 into /usr/lib/perl5/site_perl, then you will need to turn1476 /usr/lib/perl5/site_perl/ and its subdirectories into1477 install directories. You don't need to do this now as you'll notice it1478 anyway when installing a perl add-on fails.1481 autoconf:1482 The autoconf package wants to install its own copy of standards.info,1483 which fails because binutils has already installed this file. You can1484 either ignore the error or remove the binutils version of standards.info1485 before `make install'.1488 bash:1489 configure:1490 The bash configure script tests for the presence of the special devices1491 /dev/std* and /dev/fd/*. Unfortunately at the time of this writing the1492 test for /dev/fd/* is buggy (the test for /dev/stdin used to be broke, too1493 in bash-2.x, but has been fixed since). It ends up testing read access to1494 standard input,1495 which is the (pseudo)terminal you're building your system in.1496 Unfortunately su doesn't change ownership of the terminal device, so when1497 you're su'd to a package user account, the terminal still belongs to the1498 login user. As the package user doesn't have read access to the device,1499 the tests fail.1501 There is a simple way to get around this. Simply run ./configure like this1503 ./configure .... </dev/null1505 The trick here is to redirect standard input (note, that this is a '<' not1506 a '>' !) to refer to /dev/null. Unlike the terminal device, /dev/null is1507 world-readable and world-writable, so the tests succeed as they should.1508 If you don't like this trick, you can also chown the terminal device in1509 question (see `ls -la /dev/fd/0') to the package user before building1510 bash.1512 make check:1513 When running the test suite as a package user, the test "run-test" will1514 fail with the output like this:1516 33d321517 < *** chmod g+s /tmp/test.setgid1518 35c341519 < 11520 ---1521 > 01522 64d621523 < *** chmod u+s /tmp/test.setuid1524 66c641525 < 11526 ---1527 > 01528 154c1521529 < 11530 ---1531 > 01532 160c1581533 < 11534 ---1535 > 01537 The first 2 failures are caused by the chmod wrapper which prevents the1538 test from setting the setuid and setgid bits and outputs the *** warning.1539 The failures are harmless. You can get rid of them by removing the wrappers1540 directory from the PATH before running the tests.1542 The last 2 failures are not specific to package users but will occur1543 whenever you run the tests su'd to another user. The reasons are the same1544 as for the configure problem described earlier. The same solutions apply.1545 Either use chown (if you chowned before configure you're already1546 done, of course) or run make check like this1548 make check </dev/null1550 make install:1551 Before you can `make install' you need to `chown -h bash: /bin/bash' as1552 root so that the bash installation can replace the /bin/bash symlink that1553 you manually created at the beginning of chapter 6.1556 pkgconfig directory:1557 At the time of this writing the directory /usr/lib/pkgconfig is1558 created during the e2fsprogs installation. This directory contains1559 build information used by the pkg-config tool. Other packages want to1560 install files into this directory, so you should make it writable by the1561 install group and sticky.1564 grub:1565 The commands to create and populate /boot/grub have to be executed as1566 root.1569 grep:1570 Before you can `make install' you need to `chown -h grep: /bin/grep' as1571 root so that the grep installation can replace the /bin/grep symlink that1572 you manually created at the beginning of chapter 6.1575 inetutils:1576 This package contains some programs that it wants to be setuid root:1577 rsh, rcp, rlogin and ping1578 The install wrapper prevents these programs from being installed1579 setuid root. You must decide which of these programs you want to be1580 setuid root and manually make them so. Be conservative. Don't make a1581 binary setuid root unless you *know* that ordinary users can't live1582 without it. Every setuid root binary is a potential security hole.1585 iproute2:1586 This package tries to change the permissions of /usr/sbin and some man1587 directories. The install wrappers take care of this.1590 man-db:1591 Even after installing man-db you won't get manpage summaries from1592 list_package, because the way list_package calls man it needs col1593 to work and col is from util-linux. You may however install util-linux1594 right away. The alphabetical sort is the only reason it is at the end1595 of Chapter 6.1598 shadow:1599 By default shadow wants to install non-English manpages. This fails1600 because the /usr/share/man directory is not an install directory and1601 therefore package users are not allowed to create new subdirectories in it.1602 To solve this problem, before you `make install', open the file1603 man/Makefile, find the line1605 SUBDIRS = cs de es fr hu id it ja ko pl pt_BR ru zh_CN zh_TW1607 and remove all the languages that you don't want to install. For those1608 languages that you do want to install, create directories with the1609 respective names in /usr/share/man as root and make them install1610 directories (i.e. group install, group-writable, sticky).1612 There is yet another issue with shadow concerning manpages. The shadow1613 package contains a passwd.5 and a getspnam.3 manpage.1614 Installation of these manpages is1615 automatically suppressed by the install wrapper, because it would1616 overwrite the manpages provided by the man-pages package. As usual1617 the man-pages version is better, so you can simply ignore this issue.1619 shadow wants to install the programs su, chage, chfn, chsh, expiry,1620 gpasswd, newgrp and passwd as setuid root. You will need to decide which1621 of these programs you want to be setuid root and manually make them so.1624 sysklogd:1625 sysklogd's Makefile has /usr/bin/install hardwired as the install1626 program, which circumvents the install wrapper. The wrapper is needed1627 for sysklogd because it tries to make its manpages owned by root1628 (which obviously a package user is not allowed to do).1629 Therefore, install with1631 make INSTALL=install install1634 udev:1635 udev wants to install files into the directory /usr/lib/pkgconfig. If1636 you've followed the instructions given further above you've already made1637 this an install directory. If you haven't, do so now or the udev1638 installation will fail.1640 The LFS instructions for installing udev tell you to execute the command1642 mknod -m0666 /lib/udev/devices/null c 1 31644 Because a package user is not allowed to create device nodes, execute this1645 command as root.1648 util-linux:1649 util-linux wants to install write as setgid tty and u/mount as1650 setuid root. The wrappers catch this, so it doesn't cause the install to1651 fail, but as usual you'll have to decide if you want these programs to1652 have special privileges and take manual action as root if you do.1655 ##########################################################################1656 8. Sanity Checks1657 ##########################################################################1659 8.1 Suspicious Files1660 --------------------1662 You probably ran the `list_package' command for each package and reviewed1663 the results which include the suspicious files owned by that package. But even1664 if you did that it's still a good idea to run the non-package specific1665 `list_suspicious_files' command once your build is complete. There could be1666 something you overlooked the first time, or maybe you created a file as root1667 with the wrong permissions. It doesn't hurt to check again and this will also1668 give you the opportunity to review any setuid/setgid decisions you made with1669 respect to the installed binaries.1671 TIP:1672 When you check the list of setuid and setgid files, don't forget to1673 look at the actual user or group ownership of the file. It's easy to forget1674 that, especially in the setuid case, because we often equate setuid with1675 setuid root since setuid is seldom used with other user accounts.1678 8.2 References to Temporary Files1679 ---------------------------------1681 One big concern when building an LFS system is independence of the new LFS1682 system from the files installed in /tools. The /tools directory is intended1683 to be temporary and it should be possible to delete it after building your1684 LFS system with no adverse side effects. The `grep_all_regular_files_for'1685 script from the more_control_helpers package can help you verify that your1686 new LFS system is indeed clean. The command1688 grep_all_regular_files_for /tools1690 will give you a list of all files that contain the string "/tools". Review the1691 files in the list to make sure that no dependencies on the temporary files in1692 /tools have crept in. But remember that results from binaries and libraries1693 are only meaningful after stripping away the debug information, because1694 debug information necessarily includes references to the build environment.1695 Of course, if you are a developer who will potentially run gdb on system1696 libraries/binaries, your position will be that stripping away debug information1697 is the wrong way to do away with /tools references. The other way to deal with1698 them is to rebuild packages for which /tools references are reported. The new1699 build will not involve any files from /tools and so the new debug information1700 will not refer to /tools. Note that the LFS build instructions for glibc1701 make glibc compile against /tools/glibc-kernheaders. Unless you copy the1702 glibc-kernheaders directory to a location outside of /tools and compile glibc1703 against that copy, you won't get rid of the /tools references in glibc's1704 debug information.1705 No matter what means you choose to deal with the debug information issue, in1706 the end you should have a system where the above command produces only false1707 positives (such as "perlfaq3.1", which includes the URL1708 "http://www.research.att.com/sw/tools/uwin/") and files that legitimately1709 refer to /tools (such as a copy of this hint file).1712 ----------------------------- APPENDICES ----------------------------------1715 ###########################################################################1716 Appendix A: Security Issues1717 ###########################################################################1719 A.1 NFS1720 -------1722 If you use the network filesystem NFS, there are some things you need to1723 look out for when using the package user system. A fundamental security1724 problem with NFS is that it blindly trusts the UID and GID of the client.1725 If an attacker can get access to the root account on a system in your network1726 that is allowed to mount NFS shares from your server, or if the attacker can1727 attach his own computer to your network, then this attacker can pretend to be1728 anyone. NFS will happily allow the attacker to work in the NFS exported1729 directory as any user he wants to be. The only exception is the root account.1730 By default NFS exports directories with the root_squash option that maps all1731 incoming requests from uid 0 to anonuid (65534 unless set in /etc/exports)1732 and gid 0 to anongid (65534 unless set in /etc/exports). This protects files1733 owned by root:root. On a normal system this includes most files in /bin, /etc,1734 /lib and most other directories except /home. If you use the package user1735 scheme, however, most of these files are owned by package users. These files1736 are not protected by the root_squash option. In order to make NFS exports1737 secure, you have to add the option "all_squash" to every entry in /etc/exports1738 that exports a directory that contains files owned by package users. Note that1739 all_squash is always a good idea because even systems that don't use package1740 users often have some programs owned by other users or groups, because they1741 need to be setuid or setgid.1744 A.2 Daemons1745 -----------1747 It is a common practice to run daemons under special user accounts rather1748 than as root as a security measure. If you feel tempted to use a package1749 user account for this purpose, resist the temptation. It would be a very1750 stupid idea. Although they are deliberately less powerful than root, package1751 user accounts are still privileged and need to be considered as equivalent to1752 root as far as security is concerned. Do not do anything with a package user1753 that on a system without package users you would not do with the root account.1756 ###########################################################################1757 Appendix B: Package Categories1758 ###########################################################################1760 Although the user name = group name scheme is recommended by this hint, it is1761 not the only possible one. Another scheme that has some appeal is to define1762 package categories and to use the group for the purpose of categorizing the1763 packages. Following is a suggested set of categories that can serve as a1764 guideline for implementing this scheme.1766 devel: development related stuff, e.g. compilers. This is not restricted to1767 software development. TeX for instance would belong in this group.1769 utils: Most software fits into this category, even somewhat essential software1770 like grep or text editors.1772 net: network related stuff such as an ftp daemon or a web browser. This1773 group overlaps with other groups to a large extent. It should be used1774 in preference of the other groups whenever a package is clearly focused1775 towards Internet, LAN, WWW,... A utility like wget for instance would1776 go in net rather than utils. Exceptions from this rule are the groups1777 docs, addons, games and mmedia. If a package fits into one of those1778 groups, use the respective group instead of net.1780 docs: Documentation related packages, such as a tarball with Linux howtos.1781 Note that software to create documentation such as XML processors should1782 probably go in devel and software to view or post-process documentation1783 such as man or groff should probably go in utils.1785 system: important system software, such as bash. This group should be used1786 only for really essential packages. Most packages you would put in1787 this group are better put in "utils". Vi for instance belongs in1788 utils.1789 It is unlikely that any package not part of basic LFS belongs in the1790 system group.1792 libs: What utils is for executables, libs is for libraries. Libraries that are1793 not strongly related to any of the other categories should go here, such1794 as zlib or libpng.1795 Essential system libraries such as glibc, ncurses or gettext should1796 go in system instead.1797 The libs group is also used for run-time environments such as the1798 Java Virtual Machine, dosemu and wine. Other emulators like MAME for1799 instance should probably go into games instead.1801 games: what do you expect ;-)1803 mmedia: This is the group for audio and video editors, mp3 players etc.1805 apps: Applications such as spreadsheets and word processors (not text editors)1806 but also CAD software and graphics software such as Gimp.1807 The apps group is a bit like utils, but apps are usually more user1808 friendly and more streamlined and feel less nerdish than utils.1810 addons: plugins, filters and similar that are meant to be used in conjunction1811 with another package.1813 x: software that relates to the X Window System in general and does not fit1814 into any of the other categories, such as the X server itself or window1815 managers.1816 Most X software should be put into other more specific groups.1817 A game like xmines would go in games for instance and a text editor for1818 X would go in utils.1820 kde: Software that relates to KDE and does not fit into1821 any other category. This group should be used with care.1822 Do *not* use it for all KDE software. K Office for instance belongs in1823 apps. Konqueror belongs in net.1825 gnome: Software that relates to GNOME and does not fit into1826 any other category. This group should be used with care.1827 Do *not* use it for all GNOME software. Gimp for instance belongs1828 in apps. A GNOME-aware window manager that works with plain X should1829 go in the x group.1832 ###########################################################################1833 Appendix C: Acknowledgements and Changelog1834 ###########################################################################1836 ACKNOWLEDGEMENTS:1837 * Matthias Benkmann for writing the original version of this hint1838 * Tushar Teredesai for suggesting the user=group scheme.1839 * Markus Laire for reporting the 2005-01-01 build bug1841 CHANGELOG:1843 2007-10-20 Matthias Benkmann1844 -relicensed under CC-BY-SA (previously CC-BY-ND).1845 -added name tags to changelog entries in preparation for having the1846 hint continued by different authors.1847 -added workaround to list_package for bug in man-db that causes1848 some manpages to show up as "Weird manpage" in the summary.1849 -chmod wrapper now prevents shadow from installing files setuid1850 shadow.1851 -added a wrapper to solve ldconfig issue.1852 -install_package now works when called with just a single argument.1853 That argument is used for user name, group name and description.1854 -bash_profile of more_control_helpers now has /sbin and /usr/sbin1855 in the PATH to match the PATH used by root when building.1856 -install_package does su - <name> now (i.e. start a login shell).1857 -build script now handles unpacking of tarballs and allows calling1858 the different stages individually.1859 -useradd uses the -s provided shell and no longer hardwires bash.1860 -chapter 6 bash notes now properly address the configure and1861 make check issues.1863 2007-03-21 Matthias Benkmann1864 -changed forall_direntries_from to avoid warning message from find1865 when -depth is used.1866 -added 4.8 What Commands to Run as a Package User1868 2005-12-22 Matthias Benkmann1869 -added advice on how to cope with the moving mv problem to1870 coreutils note.1872 2005-11-13 Matthias Benkmann1873 -fixed list_suspicious_files and list_package to work with1874 recent more POSIX-conforming versions of GNU find1875 -released version 1.21877 2005-01-01 Matthias Benkmann1878 -fixed bug in skel-package/build script that caused it to report1879 all steps as successful, even if they failed1880 -released version 1.11882 2004-11-01 Matthias Benkmann1883 -capitalized title1884 -released version 1.01886 2004-10-14 Matthias Benkmann1887 -started developing the more_control_helpers utilities1889 2004-08-14 Matthias Benkmann1890 -started major rewrite (update for new LFS version, new hint1891 format, textual improvements,...)1893 2002-04-20 Matthias Benkmann1894 -changed LFS VERSION header to be more conservative1895 -added <br> tags to the synopsis for the sake of the hints1896 index1897 -added group mmedia to the list of suggested groups1898 -submitted v0.81900 2002-03-16 Matthias Benkmann1901 -added note, that on Linux make doesn't need to be setgid kmem1903 2002-02-18 Matthias Benkmann1904 -added section "Security issues with NFS"1905 -submitted v0.71907 2002-01-30 Matthias Benkmann1908 -added Changelog1909 -moved "chown 0.10000 `cat /tmp/installdirs`" command up (before1910 glibc package user is created)1911 -add_package_user: create home directory with "mkdir -p"1912 use $grpfile everywhere instead of /etc/group1913 -improved mammoth sentence in Introduction1914 -added note about possibility to have user name==group name1915 -source bashrc_basic in bashrc_package1916 -minor textual changes