Add the Ability to Use Without Root

[digitalsignalperson]

Description

running pacman-venv venv asks for sudo password for "Installing base environment"

can it be rootless?

Same for installing packages in the venv, it asks for sudo password.

What alternatives have you considered?

No response

[jdholtz]

Not that I know of as you are using pacman to install the packages and pacman requires root.

[digitalsignalperson]

hmm, I don't know much about namespaces, but that seems like an option

something from from this thread https://www.reddit.com/r/archlinux/comments/xbtcl8/make_pacman_work_without_root/

Use arch-chroot with -N. Note that the permissions will only look correct inside the chroot. This is because you really do need root permissions in order to create files as the root user. In general, this means you have to use pacstrap with -N as well.

from the manpage:

-N
Run in unshare mode. This will use unshare(1) to create a new mount and user namespace, allowing regular users to create new system installations.

[jdholtz]

That looks interesting. I’ll definitely check that out.

Is there a reason rootless is desired? Pacman has a hard-coded root user check, so there isn’t any way around that by using the pacman command.

It would still be possible to use any other command inside the virtual environment that allows you to install packages as non-root. You might just have to use the --root flag (or the equivalent of that software). Support for this can also be added through a shim.

[digitalsignalperson]

You may have a scenario where you are using a computer that you don't have sudo/root access to, but you want to install some pacman packages. I think you can also argue there are some security benefits for things to be rootless in general.

With the venv concept rootless makes sense since we are not modifying the system in any way. Just like pip imagine if we had to use sudo every time for a non-system pip package install.

See also distrobox, junest, and conty all highlighting being able to be used without root as a key feature.

[jdholtz]

Those are good points. I’ll see how I can make this possible.

[digitalsignalperson]

I was just looking at how junest implements bwrap for this. One idea could be to use bwrap (or another namespace solution) in a similar way for the venv, but have the host filesystem mounted within the new root, and have the various PATH variables pointing to them as needed.

[digitalsignalperson]

i think unshare --fork --pid pacman -r "/path/to/root" -Sy packages is also similar to arch-chroot with -N

from install-arch-without-pacstrap.md

[spfanning]

The checkupdates script from pacman-contrib uses fakeroot to use pacman without root.

[jdholtz]

Thanks for looking into this! I’ll hopefully have time to implement this soon. This will be a very nice addition to the project.

[jdholtz]

I've been messing around with this for a little bit. So far it seems like unshare will work if you use the --map-root-user command: unshare --map-root-user --fork --pid -- pacman -Sy --cachedir pacman-venv/var/cache/pacman/pkg --root pacman-venv/ packages.

I also tried using fakeroot, but it kept throwing this error:

could not change the root directory (Operation not permitted)
error: command failed to execute correctly

I used the following command: fakeroot -- pacman -Sy --cachedir pacman-venv/var/cache/pacman/pkg --root pacman-venv/ packages

I'll have to look more into why this error is only occuring with fakeroot.

A disadvantage I noticed while trying to use pacman without root access is the need to use another cache directory. Unfortunately, /var/cache/pacman/pkg (I also tried with a symlink) is only accessible to root, so a new cache directory will need to be used for every virtual environment. The disadvantage to this is that a lot more disk space will be used. However, it could help to isolate the virtual environments more (although pip uses one global cache when running in virtualenv).

[digitalsignalperson]

Interesting, that makes sense that /var/cache/pacman would be read-only, since an unprivileged user could just stick a malicious package into the cache used for system packages.

Maybe there's a way to use the system cache if what the venv needs is in there, otherwise write to a venv or user-level package cache. Possibly symlinks? or overlayfs? Or maybe some shell script to manually copy/link the specific files, like a pre-pacman hook.

But I agree it might just be KISS and some level of isolation to just not care about sharing the cache.

Unrelated but this reminds me of how I already waste a lot of space forgetting to use paccache -r (maybe I should auto run that with a pacman hook or something)

[digitalsignalperson]

also this reminds me of virtualenv --system-site-packages venv

[jdholtz]

Maybe there's a way to use the system cache if what the venv needs is in there, otherwise write to a venv or user-level package cache

I did try with symlinks and but pacman appears to always need write-access to the cache, even when I installed the exact same packages that I had in my cache already. It threw a warning that said something along the lines of could not find or access cache directory. Using /tmp.

also this reminds me of virtualenv --system-site-packages venv

That’d be an interesting feature to add. Currently though, it doesn’t appear to be possible since pacman doesn’t support searching multiple DBpaths at once (AFAIK). Also, pip has special flags to work better with including system site packages in virtual environments. Unfortunately, there is not the same level of support for pacman.