Why do package managers require root priveleges?

Question

The default package manager for mainstream Linux distros (deb/apt, yum/dnf, pacman, etc) do global-installation by default and require root. It seems better to install as user or group and not need root, because one would run less untrusted code as root (as Nix, Guix, Cargo, Pip, Gem, Cabal, Stack, CPAN).

To save space on shared systems, one could install packages to directory which is readable by users but writable by admins, but this doesn't have to be root, and it should still permit users to install their own packages.

Package that modify protected files like Grub or provide services would need to modify the root system, but everything else should be doable from user-side.

This question says that packages may assume they are installed to specific locations in the Filesystem Hierarchy, but I thought this could be fixed by setting $PATH, $LD_LIBRARY_PATH, and friends. And otherwise, why not just have a wrapper that runs the program in a chroot?

Answer 1

You are speaking about system package managers, which install system libraries and shared programs (and possibly also daemons), for that reasons they requires root privileges.

There are some user-space package managers, e.g. flatpack, but if you look at them, you may see some problems:

• you must learn two (or more) package managers, and you may confuse where some programs come from (system or user?)

• dependencies are more complex: a package manager at a level cannot see dependencies of the others. E.g. if I upgrade the version of my OS, it is possible that this break some users, and I cannot check all programs installed by my users. But also the contrary: my user-space package manager cannot influence the system packages. If it need a specific version of a package, you need it, or you are lost. For this reason, most of such user-space packages tend to includes requires dependencies (and libraries).

• it makes much harder to handle a system (in case you find a way to integrate the two).

Note: computer languages (Python with virtual environments, javascript with node.js, and many other languages) may have own system (similar to package manager) to handle libraries and other programs.

In short: it is difficult, and now we often prefer docker: there is a clear separation between system an my container (and simple boundaries: file systems, network). Now probably we have much more support (shadow file systems, separate namespaces, etc.) to allow user packages well integrated on a system, but it doesn't really solve the problem about easy maintenance of the system, and users may run dangerous (old vulnerable programs). I think it may be feasible now, but there is not much demand (or volunteers) to do it.

PS: you can really screw up other users, by installing a new version of a library, or by installing some programs like sl, les, etc. (so typos of common commands): easily you can get all powers of such user.