Randy McMurchy wrote:
I'd like to work with you on this one (meant as I'd like to give what you're saying a chance, and not just dismiss the idea).
Thank you.
What exactly do you mean by "more control". I suppose this is what is confusing me. I am interpreting "more control" as something that would allow folks to put files where they want and such, which I think would be a bad thing, so I'd like to know what you mean as
Please be patient as I give a little background info for those not aware of what the hint is about:
As you may or may not know, in his hint, Matthias has you run the build of each package from chapter 6 on as a non-privileged user. More to the point he uses a new user for each package (and they're always given a UID within a certain range and made part of the 'install' group that owns such group-writable directories as /bin and /usr/bin).
Part of the purpose behind this is that you can then quickly see what files this package has installed by searching the filesystem for items owned by that UID. Also the home directory for each package is placed in /usr/src/[package-name] and there you can keep tarballs, build-notes, etc. This part of the hint is the package management aspect. While I appreciate these benefits, I was more interested in the 'more control' part, as follows.
By building and *installing* each package as a non-privileged user, whenever an install script tries to silently setuid root a binary or it tries to change ownership of a file or directory, the install script fails and you as the user in charge has to decide what to do. Do I want to allow this program to run with root privs? Do I want this new package to change ownership of this file or directory that's already installed on the system? When you decide, you take the appropriate action (Matthias has simplified some of it in his scripts, but at times, it's up to you to edit the Makefile in question, etc.)
As you do this for each package you could see that you would begin to see a lot more about what their respective install scripts are doing. You wouldn't be changing default locations for packages (not that that's a huge deal - we do that in LFS anyway for some packages) nor are you changing the functionality. But you are limiting what freedom a install script has on your system. Why is it so important to run './configure' and 'make' as a non-priv user but we freely allow root to run the most dangerous one, 'make install'?
Now, if there is another way of achieving what Matthias has done - one where we don't have to have a separate user for each package - that would be great. In short, what I'd like to see is a clearer understanding of the packages being installed - the ability to audit the installation of packages and determine a proper course of action for each.
Gerard understood what I was after and what I am looking to incorporate: http://archives.linuxfromscratch.org/mail-archives/lfs-dev/2005-November/054332.html -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
