The point I made was there. I can offer no more, so best of luck to you. You should perhaps read up on root privilege escalating. Plus here's a good question, will you be able to auto-manage the numerous user accounts created per package? Remember the more you install the more accounts you need.

Package User is very complex, even though I've read through Matthias' documentation at LFS-Hints, and seriously it has good points, but it, to me, leaves a lot to be desired that existing package management tools have. Not having root execution access and read/write to system resources is going to give you loads more work than necessary. Knowing what is in packages and the permission levels of files is already done through other means, especially using a catalog file. Stuff must still be done as root with Package User.

1. Catalog files can be created by the package manager and read with cat or tee easily if plaintext.

2. Most package managers use the catalog from the decompressed archive to tag files for uninstall, especially cmake stuff.

3. This is where user based permissions can work. Use the catalog and script in chmod changes either pre-package or post-install.

4. Packages shouldn't be overwriting files, but you can also check things pre-package or execute build instructions to prepend a prefix to the content, similar to how elfutils and binutils install. The only time an overwrite should occur is a package upgrade.

5. I never use rpm anyways. I prefer tarballs compressed for xz, lmza, or gz aka .tgz, .txz, or .tlz.

6. Most good packaging stuff is ran off scripts anyways in UNIX stylizations anyways, at least in my system.

You are claiming that using the package user method is more unsecure than using the lfs and blfs as it is. Yet you have failed to show any real world examples of how this can be. Instead you try to defend yourself by comparing the package user method to other package methods.

Wayne Sallee
Wayne@WayneSallee.com

In 2013 Robert Taylor built LFS 7.4 with user based package management ala the documentation at LFS-Hints. In the process he reworked Matthias' scripts and added several new ones, addressing many of the complexity issues you cite. Ultimately, he made these reworked scripts available as "more control helpers" Version: 1.6.2

You can read his build notes here, along with a very good tutorial on user based package management.
https://www.javacrypt.com/lfs/my_lfs..._for_1.6.2.txt

Regards,
James Rasmussen

Showing an actual incident of root priviledge escalation is difficult, but I can provide an example:

http://www.admin-magazine.com/Articl...ege-Escalation

Now I'm asking, how secure is Package User for your system and how are you going to implement security standards to coincide with it?

There was a good reason I asked about security patches and known stable packages.

On a side note:

Regardless of any package management technique you try, whether it be package user, pkgtools, pkgutils, rpm, etc. always try to stick to stable and trusted packages, and patch as needed, mostly aimed at securing packages and the system. Never leave anything to chance, and use care, and of all things, make backups.

Hi Wayne

In reply to your original question, I use the package user management method and always have done (11 years now - geez is it that long).

I've changed it quite a lot over those years compared to Matthias's original hint, but the essence is the same.

I have a script for LFS which creates the scripts for the required chapters (Chapter05, Chapter06 and Chapter08)
I have a script for BLFS which creates the scripts to install each section (from Security all the way to PST).

Things got a bit complicated with the introduction of systemd and now I think the scripts are probably too complicated for anyone to get to grips with them, so I wouldn't recommend you taking them on - unless you are an expert at Bash.

I have a github site where the scripts are available. Let me know if you are interested and I'll put the latest versions up there. The current ones are way out of date and I don't update them very often as no one uses them AFAIK, except me of course

Regards

John

By all means post a link to your scripts. Even if I don't use them, someone else could benefit.

So it sounds like you have built several lfs blfs with the package user method?

How much use have you gotten from them, ie have they been working well as your main operating system?

Wayne Sallee
Wayne@WayneSallee.com

I've updated the github site.

The LFS scripts are at:

https://github.com/JohnBurrell/LFS-BuildScripts

and the BLFS scripts at:

https://github.com/JohnBurrell/BLFS-BuildScripts

so you can download them using git clone https://github.com/JohnBurrell/LFS-BuildScripts.git
and obviously BLFS-BuildScripts.git for the BLFS scripts.

The scripts use dialog to set up a config file. There are quite a few options now and not all possible combinations have been tested, so there are bound to be things that break. I usually build using systemd, so the sysvinit option has not been tested recently. I also build as a package user, but you can choose to build as root - but that hasn't been tested recently either.

I use the scripts as a test bed. For e.g. in BLFS I've recently been scraping websites for the latest source versions to update the wget-list file for each section.
I've also added a DESTDIR install to create package binaries so you can install and update LFS and BLFS as you do Arch Linux.

Each README is out of date, but if you want to try and use the scripts, let me know and I can update both to explain a lot more about the latest changes.

John

Are you able to use the lfs/blfs installed by package users method as regular highly useful systems?

I am currently building mine to replace my main operating system, and was wanting to know how successful others have been in similar matters.

I'm currently using Mandriva 2010.2 which at that time was the best linux operating system, in my opinion. Mandriva is now history, and my system needs to be replaced, so I am building it now.

How much use have you gotten out of it?

Wayne Sallee
Wayne@WayneSallee.com

Yes, you can build an LFS/BLFS system using the package user method and get a useful system. However, you should realize before embarking on doing this that you will come up against problems. Most of these problems are 'permission denied' type messages. This is because a package user cannot write to a directory which it doesn't own or which isn't an install directory. The install group is set as 9999 and all package users must belong to this group. So, just to emphasize the point, all directories to which the package user needs access must either be owned by the package user or be set as install directories. This is done by:
chgrp install <directory>
chmod 1775 <directory> notice the sticky bit is set so non-owners cannot remove files.

This can be a pain when installing some packages. This is why I started to write the scripts - they set these install directories for a package before compilation.

The other pain is that some packages change the owner and permissions on existing directories. attr and acl are examples of this, but there are plenty others. They try and change /usr/bin /usr/lib /usr/include /usr/share/man and others and a package user doesn't have permission to do this. This means you have to edit the Makefiles to remove these offending commands. So in the scripts, there are a load of sed commands which remove these lines from the Makefiles.

Also any files which are setuid root binaries cannot be installed by a package user. Usually the file is installed okay, but you have to chown root and chmod 4755 (or whatever) afterwards if you wish. You can see this is an advantage because you don't want these permissions if they're not essential because the binary will give access to system resources to any user when it's running - not an ideal thing to do.

The main reason I use this management method is to easily list all files owned by a package user and to delete those files when uninstalling a package. And to control the files that a package writes to the system. For example, I don't use the /usr/libexec dir so if a package tries to write to it, the install fails. I can then set --libexecdir=<some dir> in the configure.

But doing all this manually is a PITA, particularly the first time and will take you ages sorting out what each package is doing because you have to inspect the log files to see what happened.

Using the scripts makes it manageable for me. However, you really need to write your own scripts, because it'll take you ages to understand what mine are doing and to be in a position to change them to suit yourself.
Unless, of course, you're sh*t hot with Bash, Sed and Gawk. In which case, you'll walk it.

John

I'm already a good ways into BLFS, so I am very much aware of having to work around the obstacles of using the Package Users Method. It is more work, but it's also more educational, and gives you more control.

I'm interested in knowing how successful others have been with the Package Users Method.

How far have you gotten with the Package Users Method?

Wayne Sallee
Wayne@WayneSallee.com

I'm interested in trying it out, but I think it would be a bit of a hassle in the log run (for me at least). I do plan on going through it once via a normal LFS build though for the learn experience, but I don't think I will use it more after that. In a test build I have got going on at the moment, I've managed to install pacman successfully and I am working towards making my own set of PKGBUILDs. This will probably be my own way of package management moving forward, once I have gone through the effort of writing all these PKGBUILD files and creating a test system to try it out on first.