paru
paru copied to clipboard
Allow users to build AUR packages from root with a flag
Have you checked the readme and man page for this feature? yes Have you checked previous issues for this feature? yes ~~I know about all the security risks and whatever, but sometimes those don't apply. There should be a flag to allow users to build AUR packages as root.~~
~~Sometimes what the user wants is more than what is best practice ;)~~ Edit: Since building as root is a bad idea, it would be a good convenience feature to automatically de-escalate and build as a different user, then install files escalated.
Packages are always installed as root...
If you mean building a package as root then that flag won't do anything because makepkg (which paru calls) will still not let you build as root.
If you mean building a package as root then that flag won't do anything because makepkg (which paru calls) will still not let you build as root.
Yeah, that's what I meant. It's possible to patch makepkg to allow execution as root, but it doesn't seem to be as easy in the case of paru.
Well you would patch paru the same way. But if you're going to go through all this trouble to run makepkg as root, why not go through the trouble to learn how not to run makepkg as root? Surely it's a similar amount of effort.
http://allanmcrae.com/2015/01/replacing-makepkg-asroot/
Well you would patch paru the same way. But if you're going to go through all this trouble to run makepkg as root, why not go through the trouble to learn how not to run makepkg as root? Surely it's a similar amount of effort.
http://allanmcrae.com/2015/01/replacing-makepkg-asroot/
Well surely it would be faster to type paru -f ...
with a patched makepkg than git cloning from the AUR and using makepkg with that. I guess this is a niche use case.
Maybe paru could run as its own user if it detects it's being run as root? It doesn't sound ideal though.
Why doesn't paru just use a dedicated parubuild
user to compile packages?
@kotx why you want to build a package as root user?
E.g. because I am writing a dockerfile and wish to avoid the complexity of creating a sudoers file…
Sometimes I want to install a package while setting up a new system that I know is 100% safe, and it's a hassle switching between users, visudo
ing, etc.
Sometimes I want to install a package while setting up a new system that I know is 100% safe, and it's a hassle switching between users,
visudo
ing, etc.
Though I'd call that a bad reason because the claim of being able to assume "100% secure" is likely dubious. Paru should be usably secure and that involves not building as root.
I just think there is a way of dropping to a safe user without requiring invocation with sudo. It might even have advantage because the extra build user would provide a consistent build environment.
There's no reason for this at all, and in fact it is a security risk. Building software as root is a horrible idea. I don't understand why you'd want to do this because it's easy to drop to a normal user when building software.
Perhaps instead a feature to drop down to another user for building the packages if paru is run as root could be added. However, not even makepkg supports building software as root so adding support for it to paru would require forking makepkg, and overall it's an extremely bad idea, that shouldn't even be considered.
@koraa , to create an image which allows building as root in docker, i am patching makepkg, add a build user, add it to sudoers and then run things as that user (https://github.com/soloturn/build-aur-action/blob/master/Dockerfile):
RUN pacman -Syu base-devel git --noconfirm --overwrite '*' && sed -i '/E_ROOT/d' /usr/bin/makepkg
RUN useradd -m -G wheel -s /bin/bash build
RUN perl -i -pe 's/# (%wheel ALL=\(ALL\) NOPASSWD: ALL)/$1/' /etc/sudoers
USER build
then use it like here: https://github.com/soloturn/swift-aur/blob/master/.github/workflows/swift-language.yml . which calls the entrypoint.sh: https://github.com/soloturn/build-aur-action/blob/master/entrypoint.sh
running the patched makepkg. but now as you say i am wondering if it not could switch the user to "build" ...
I would love it if you could configure it to de-escalate permissions for build process, and then revert to root for install. It's always annoying when you forget to de-escalate before running paru
-- and also annoying that you can't predict when you'll need to come back to supply your password.
I am trying to use paru
in an unprivileged container (using Singularity). To allow paru
to install dependencies in the container, running paru
as root is required, because in the container, sudo
doesn't have the setuid bit set (root is actually a fake root).
I completely understand and agree that paru
shouldn't be run as root on regular systems. As noted by @koraa, I agree that convenience isn't enough of an argument.
I am proposing that a version of paru
could be compiled specifically for unprivileged containers. I implemented it using Rust Conditional Compilation (ie feature). See #665
Please let me know what you think.
Automatic de-escalate -> build -> return for install would be a great convenience feature, wouldn't risk security, and it would allow the docker use-case as well, afaict.
I would love it if you could configure it to de-escalate permissions for build process, and then revert to root for install.
Gentoo has a tool for managing live packages called smart-live-rebuild, ran as root, it drops permissions during the build phase to not have to invoke sudo. This would seem like a good pattern to follow for paru as well as it would remove the need for sudoloop and the maintenence burden of calling sudo at all.
This strategy would allow for completely unattended and scripted installs using paru.