You are way out of order pal! Personal atacks are really not welcome, Reaper is one of the long time pillars of this forum and you would be advised to listen to his advice even if you choose not to act on it, and NO MORE PERSONAL ATTACKS!

Here's my take on some of these methods...

Some of these methods, like Package Users, is very complex, and requires a lot of knowledge beforehand to integrate into the system, henceforth, why not a lot of information exists on it. It's a method, but it's complexity makes it a turn off for people wanting a simple solution to a complex issue.

Package management is, like anything, a complex issue, mostly due to the fact that any time a system is updated in a package, especially a dependency library, something can go wrong and break the system, unless you're willing to rebuild a lot of packages. It doesn't sound like much, but in reality it's a huge problem. If you don't think so, run ArchLinux or Gentoo/Funtoo Experimental for a year, then come back. You may have changed your tune.

The reason we offered insight into pkgtools, pkgutils, and others is because they offer a simple method to reduce the needless complexity and offer a solution that is readily available, known, trusted, and stable with lots of documentation and testing.

The reason some of these methods exist are because people contributed to promoting them inside B/LFS as hints, but to be honest with you, B/LFS has only one promoted package manager, the combination of make and tar using DESTDIR="" in a temp folder, the Fakeroot method, or just using make with an archived source package pre-configured, pre-patched, and ran with 'make clean', aka 'old-school UNIX style'. Everything else is hinted at due to the complexity involved. If you want real complexity, look at overlayfs which uses a file system mounted for each package at boot time. It's the same method used by Android, and it's brain-breaking to try and implement, and it tends to fail with actual disk based systems, a lot. It works great on RAM/ROM based media though.

If you think we're trying to promote anything, you're wrong. We'd love to help, but the problem is some of these methods are severely under-documented for a very good reason, mainly, hardly anyone is using them, and willing to document them accurately. We only commented because we are willing to share more readily usable and documented methods to help you. The ultimate decision to use them, or experiment with them, is up to you, but we did offer to help, not to hinder.

I don't know that I'd call what was said a personal attack, so much as someone upset about a thread bring hijacked; whatever. We're all friends, yes?

As regards the complexity of user based package management, this is very true. But then, Apt, RPM, Portage, et. al. are just as complex: they simply have an interface that hides all that from the end user

I really LIKE user based package management's core philosophy about avoiding set UID root, but to install something like a GUI with it (what Wayne started this thread to ask about), that would be a tremendous amount of work. I think it would also be a tremendous amount of with some of the "simpler" tools mentioned in this thread, one of the reasons, perhaps why distros that use them tend to be more command line focused.

Anyway, Wayne: if I want a GUI, the combo of choice (for me) is Debian/XFCE; there just isn't (IMO) a simple way to handle such a task.

Regards,
James Rasmussen

It would be easier to avoid the UID problem, but them problem is, each user would require multiple rebuilds and mounts of their own userspace tools rather than using permissions based access via a central hub. This would mean /usr/local would have to be broken down into multiple user based instances and it severely breaks FHS. Plus, mounting a separate /usr/local per user is not very well documented. I've seen documentation on it years ago, but the methods were slipshod at best and the documentation was severely lacking.

For example:

Each user would require their own partition of /usr/local in a disk quota, not just /home. Such as:

The problem will stem from this: how do you effectively control the user mounts of each person's /usr/local-* quota and share per login and dismount per logout? Using /etc/fstab is out of the question entirely, and it starts to become a complex mess dealing with user based mount instances. Plus, how do you control dependencies? You can try ~/.bashrc and ~/.bash_logout but you end up with the instance of creating multiple scripts per user that are uncentralized, and unrealistically, at the mercy of the user themselves.

This is why permissions based handling of users and groups became a more logical choice. You can effectively control a centralized database of users and the permissions per binary they can use. Plus you can limit resources in the /etc/groups database per user, and you lessen the amount of disk quotas in need of resource management. You build and install once, and assign permissions in the network and system, and each user has their own personal account and directory in /home for their personal files.

In the method I referenced, Robert Taylor's version of the more control helpers for user based package management, the referred to "users" are the packages themselves. In effect, each time you install a package you create a new user with a common primary group - install. Install has group permissions allowing it run wrapper scripts for chown, etc. plus other scripts necessary to install packages, but does not have root level access otherwise.

Install has an ID of 9999 and package "users" have ID's of 10000 and up. When you issue cat /etc/passwd you see all the actual users beginning at 1000, with all packages beginning at 10000. Very neat. In any given directory, a long list will show you the package "user" that owns any given file, subdirectories owned by install group and pretty much everything else. There's a searchable list that indexes all files associated with a package as well, with scripts to query the list. All the package files themselves are in a single subdirectory - /user/src - which functions pretty much like /home for actual users. Tarballs are either in a /sources directory on a file server or, in the package subdirectories themselves.

The only hang up is that you have to set up build scripts for running configure, make, etc. manually: there is no mechanism currently to parse the existing system state, determine dependencies and make these decisions for you.

That's what I meant by someone with Python skills integrating it with the 0install injector, to function as a system parsing agent.

Regards,
James Rasmussen

Ah. My mistake. You mean using a dedicated installation user group per package. Let me tell you, be careful using that. Make sure than the group you assign as the installation group is properly locked down. Installation becomes problematic when things try to access directories in /(root) like /etc. If that's the case, the install group has to have root privileges as well, which should not be done, ever.

In short, you end up with another problem.

Thanks James, You understand my comment correctly.

As for the first deskop I figured I'd go with xfce or Keith Hedger's desktop http://www.linuxquestions.org/questi...ct-4175542914/ .

One thing too about the package user method is that if a program becomes too dificult to install as package user, that program or set of programs can be installed as root. So it's not like one is locked into only being able to use the package users method. One is still free to chose to run as root whatever they want.

Using the package users method, is more work, but it's also more educational, because you learn where all those files come from, and what programs interact with what files.

Wayne Sallee
Wayne@WayneSallee.com

When you install a new program, that program will have the user name you give it and the group name "install". For example "wget" will be installed as follows as root:

install_package wget
The user wget is created by the script with the group install. The user wget has no password, so one has to become root to to become wget. wget user is as secure as root.

All directories that need to be allowed for installing programs are permissioned as following example:
chown root:install /bin
chmod ug=rwx,o=rxt /bin
So only users in the install group can install in those directories, and cannot modify any other users files.

And of course root can do anything, so the permissions does not stop root.


Wayne Sallee
Wayne@WayneSallee.com

I can also put installs in groups for example when I installed Xorg Applications and other xorg stuff I put them in the xorg group for example:
install_package xorg-applications xorg

I did this with each package that was installed as part of xorg.

When I look at the files that were installed, I can see that they are of the xorg group.
Oddly enough /etc/group shows no users in the xorg group. That's probably better anyway.

Doing this was probably not the best thing to do, but I decided to give it a try and see how it would work out, as using other groups had been suggested. All those package users are still in the install group.

Wayne Sallee
Wayne@WayneSallee.com

Hi Wayne;

Thanks for the link to Keith Hedger's thread. I'm still not sure I would ever want a GUI on a from scratch system but, maybe reading it will change my mind.

Thanks also for the example install of wget, it explains the user based package management method a lot better than I did. If you end up installing a package as root, bypassing the build script, you can still manage it in a user based manner by running install_package <foo>. The use of separate scripts for all the key functions makes it highly adaptive. And of course, it is an excellent teaching tool. I've learned a ton about installing software and making it work together in just the few weeks I've been using it. More certainly, than from years of just typing "apt-get install ..."

Regards,
James Rasmussen

The install_package script is run as root. The script then creates the user and su's you into that user in that user's home directory which is in /usr/src/<thatpackageuser>

You then run the build and install and all the instructions (with minor editing sometimes) that LFS and BLFS gives, as that user. When you are done, you type "exit" to get back to root.

There are a few rare occasions where you will need to run a configure command as root after installing that package.

I have several terminals open. One for installing the package, one for downloading files as root into /sources, one for changing folder permissions into install folders (most programs install without needing this), and another for checking files, and seeing if a dependency is installed.

If later, you need to reinstall a package, you just su to that user, and do whatever is needed.

More often than not, installing a package is real quick and simple.

Wayne Sallee
Wayne@WayneSallee.com

The problem is with Package as User is you can inadvertently give a non-root user-package a condition where privilege escalation can occur, hence why it's not used. Plus you add more vulnerability points with adding more users. If you are going to use this method, do not use stuff directly out of the book. Look for anything like security patches, hardening patches, etc. that can make sure root privilege escalation can not occur, or be forced without some heavy efforts.use stable branded packages only. It may limit new packages, but it's better safe than sorry.

I fail to see your point.

Give us an example of how a package user can have a higher risk than root.

Wayne Sallee
Wayne@WayneSallee.com

When a user or group exists in the system, unless the user or group is effectively locked down properly within the system permissions and access controls, creating a user account specifically for a single package can be hazardous.

Most packages today ran on systems like Debian, Arch, etc. build as the current user logged in or via the fakeroot utility to create a simulated root environment. There is no dedicated user for building or for each package installed. This reduces the risks of a security problem by eliminating unnecessary groups and users from the system. Now granted there are groups and users for specific applications, but these are ran with special privileges specific to the daemon, like D-Bus, and they are locked out by redirecting output to either the /dev/null node and having a no-login status by using /bin/false as the shell.

Package users have no password, so they have no login other than root, because root can do anything.

Give me a real-world example of how a package user can have a higher risk than root.

Wayne Sallee
Wayne@WayneSallee.com