[arch-general] How to build package in "clean chroot" using the "-U" parameter?
Hello, I want to autobuild a set of packages. For this process, it is not acceptable to use "sudo" as I don't want to enter some passwords and my autobuild program also has to do some other stuff with root privileges. The help page of "makechrootpkg" suggests, that there is an option for me: -U Run makepkg as a specified user But I tried this several times. So far without success. I've copied the PKGBUILD to the /tmp directory, just to be sure it is really readable by my build user. Then my command was: # makechrootpkg -c -U build -r /var/cache/PATH_TO_MY_CHROOT This now seems to download the source files and also is validating them against the stored MD5 sums. But after that I get the error ==> ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system. Seems like makepkg is called once in context of my supplied "build user" and then a second time without using the build user. Where is my mistabe? Or is this a bug in makechrootpkg? Thanks in advance Manuel
2017-12-22 14:02 GMT+01:00 Manuel Reimer
Hello,
Hi!
I [..] was:
# makechrootpkg -c -U build -r /var/cache/PATH_TO_MY_CHROOT
You can do the following: # su - user -c "command" In this case: # su - user -c "makechrootpkg -c -r /var/cache/PATH_TO_MY_CHROOT" Greetings -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 12/22/2017 02:16 PM, Óscar García Amor wrote:
# su - user -c "command"
In this case:
# su - user -c "makechrootpkg -c -r /var/cache/PATH_TO_MY_CHROOT"
Yes, of course, but then "makechrootpkg" at some point wants to call "pacman" which will fail or will cause some unwanted sudo prompt to appear. That's why I want to start with "root permissions" and only want to drop to a less privileged user for the cases where software is built.
2017-12-22 14:20 GMT+01:00 Manuel Reimer
Yes, of course, but then "makechrootpkg" at some point wants to call "pacman" which will fail or will cause some unwanted sudo prompt to appear.
Yes, because makechrootpkg uses sudo for some operations. You can set the NOPASSWD option in sudoers to avoid prompt the password. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
On 12/22/2017 08:02 AM, Manuel Reimer wrote:
Hello,
I want to autobuild a set of packages. For this process, it is not acceptable to use "sudo" as I don't want to enter some passwords and my autobuild program also has to do some other stuff with root privileges.
The help page of "makechrootpkg" suggests, that there is an option for me:
-U Run makepkg as a specified user
But I tried this several times. So far without success.
I've copied the PKGBUILD to the /tmp directory, just to be sure it is really readable by my build user.
Then my command was:
# makechrootpkg -c -U build -r /var/cache/PATH_TO_MY_CHROOT
This now seems to download the source files and also is validating them against the stored MD5 sums.
But after that I get the error
==> ERROR: Running makepkg as root is not allowed as it can cause permanent, catastrophic damage to your system.
Seems like makepkg is called once in context of my supplied "build user" and then a second time without using the build user.
Where is my mistabe? Or is this a bug in makechrootpkg?
AFAIK this should work fine, for its intended goal. Though I don't think it gets a lot of testing. makechrootpkg elevates to root if needed, using sudo. It then has to run makepkg to update sources, *before* entering the chroot for building. Usually it does that by sudo -u $SUDO_USER makepkg --verifysource, however that relies on detecting the user that ran `sudo makechrootpkg` via the SUDO_USER variable. So the -U flag can be used to specify the user to use instead. That is the first time the makepkg command is run. The second time, is inside the chroot, which should automatically be run as the "builduser" user inside a systemd-nspawn container (we don't actually use chroot). Both times, makechrootpkg will drop privileges using sudo. -- Eli Schwartz
On 12/22/2017 02:26 PM, Eli Schwartz via arch-general wrote:
AFAIK this should work fine, for its intended goal. Though I don't think it gets a lot of testing.
Question is: What is the intended goal. I guess it is not what I want to do?
makechrootpkg elevates to root if needed, using sudo.
... which doesn't help me. My autobuild process runs as root. It also directly updates the chroot which also needs root permissions so it's the best to start with "root" and then drop privileges for the tasks that shouldn't run with root privileges. The whole system is a dedicated build VM, so there is no reason to not use "root" for the main purpose of this machine.
It then has to run makepkg to update sources, *before* entering the chroot for building.
That seems to be the one that works for me.
That is the first time the makepkg command is run. The second time, is inside the chroot, which should automatically be run as the "builduser" user inside a systemd-nspawn container (we don't actually use chroot).
And this one fails. But why? Does makechrootpkg for some reason miss to drop privileges if the "-U" parameter is used? Manuel
On 12/22/2017 08:31 AM, Manuel Reimer wrote:
My autobuild process runs as root. It also directly updates the chroot which also needs root permissions so it's the best to start with "root" and then drop privileges for the tasks that shouldn't run with root privileges. The whole system is a dedicated build VM, so there is no reason to not use "root" for the main purpose of this machine.
makechrootpkg already runs systemd-nspawn to enter the chroot and run pacman -Syu as the root user, so this isn't strictly necessary.
That is the first time the makepkg command is run. The second time, is inside the chroot, which should automatically be run as the "builduser" user inside a systemd-nspawn container (we don't actually use chroot).
And this one fails. But why? Does makechrootpkg for some reason miss to drop privileges if the "-U" parameter is used?
The -U parameter is completely ignored in the chroot. Once sources are downloaded, it runs systemd-nspawn to enter the chroot as root, then runs /chrootbuild, which uses a hardcoded command: sudo -iu builduser bash -c 'cd /startdir; makepkg "$@"' -bash "$@" Once you enter the chroot, nothing you do should matter, unless the chroot itself is completely damaged. -- Eli Schwartz
Em dezembro 22, 2017 10:31 Manuel Reimer escreveu:
Question is: What is the intended goal. I guess it is not what I want to do?
Well, so far you said you want to autobuild some packages and that it MUST run as root, with no good reason why.
My autobuild process runs as root. It also directly updates the chroot which also needs root permissions so it's the best to start with "root" and then drop privileges for the tasks that shouldn't run with root privileges. The whole system is a dedicated build VM, so there is no reason to not use "root" for the main purpose of this machine.
There's no reason to change the way the software gets built either. It seems to me you're trying to avoid some extra work by running everything as root.
That seems to be the one that works for me.
If you share more of what you're trying to do, and your goals, perhaps we can help more. So far it seems like a mild XY problem. Regards, Giancarlo Razzolini
On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote:
Well, so far you said you want to autobuild some packages and that it MUST run as root, with no good reason why.
I have a set of PKGBUILD's (around 40) and a self-made "build system": http://repo-make.tuxfamily.org/ The autobuild system works completely without user interaction. You just call "repo-make" and it will do *everything* that is needed to finally have a working local repository. This is meant to be used on a dedicated build VM and never on any productive system. Now my idea was to improve this process by doing every build in a chroot environment. So far my build system does things like installing packages directly, so makepkg never has to do this as this would cause silly sudo password prompts that I don't want to have in a fully automated build.
There's no reason to change the way the software gets built either. It seems to me you're trying to avoid some extra work by running everything as root.
I want to avoid unnecessary work that is not needed on a system that is meant only to be used to build some packages. If I ever trash this system, I just restore the VM from a backup.
If you share more of what you're trying to do, and your goals, perhaps we can help more. So far it seems like a mild XY problem.
I have an existing build system that I call with root permissions and from this point on it does everything on its own. Including creating the required build user, fetching build dependencies, building packages in context of the build user, ... My idea was to make use of "chroot building" to have a clean state of packages for every build. If this is possible, I would add this. If fully automated processing doesn't work with the existing tools, I'll stick with my way and keep building without chroot. Manuel
Em dezembro 22, 2017 13:55 Manuel Reimer escreveu:
On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote:
Well, so far you said you want to autobuild some packages and that it MUST run as root, with no good reason why.
I have a set of PKGBUILD's (around 40) and a self-made "build system":
http://repo-make.tuxfamily.org/
The autobuild system works completely without user interaction. You just call "repo-make" and it will do *everything* that is needed to finally have a working local repository.
This is meant to be used on a dedicated build VM and never on any productive system.
Now my idea was to improve this process by doing every build in a chroot environment.
So far my build system does things like installing packages directly, so makepkg never has to do this as this would cause silly sudo password prompts that I don't want to have in a fully automated build.
Now that things are a little more clear, I can tell you that, you mixes building software, packaging software and installing it. Of the three, only the last one (usually) requires root permissions.
I want to avoid unnecessary work that is not needed on a system that is meant only to be used to build some packages. If I ever trash this system, I just restore the VM from a backup.
If you build software always as root, you might mask some problems. I personally wouldn't trust any software that cannot be built as a regular user.
I have an existing build system that I call with root permissions and from this point on it does everything on its own. Including creating the required build user, fetching build dependencies, building packages in context of the build user, ...
My idea was to make use of "chroot building" to have a clean state of packages for every build. If this is possible, I would add this. If fully automated processing doesn't work with the existing tools, I'll stick with my way and keep building without chroot.
You keep saying chroot and I guess that arises from the name of the tool, makechrootpkg. But keep in mind that you don't actually use a chroot, you use a container. There's a difference, and it's not just semantics. To me, it seems, that all you need is to give NOPASSWD permissions to whatever user you choose to use on your VM. That way you would not get any prompts and build everything with the minimal permission set possible. Regards, Giancarlo Razzolini
On Fri, Dec 22, 2017 at 02:36:17PM -0300, Giancarlo Razzolini via arch-general wrote:
Em dezembro 22, 2017 13:55 Manuel Reimer escreveu:
On 12/22/2017 03:17 PM, Giancarlo Razzolini via arch-general wrote: I have an existing build system that I call with root permissions and from this point on it does everything on its own. Including creating the required build user, fetching build dependencies, building packages in context of the build user, ...
My idea was to make use of "chroot building" to have a clean state of packages for every build. If this is possible, I would add this. If fully automated processing doesn't work with the existing tools, I'll stick with my way and keep building without chroot.
You keep saying chroot and I guess that arises from the name of the tool, makechrootpkg. But keep in mind that you don't actually use a chroot, you use a container. There's a difference, and it's not just semantics.
I'm sorry for an unrelated question, but why is it really necessary to make a new container for each pkg? It seems lots of unnecessary copies (I think rsync(1) call in makechrootpkg doesn't do hardlinks)... I understand the issue about getting unlisted deps in packages, but in my experience this problem is minor. So just boot a build container and ssh in there as a non-root user (in fact, you don't even need root inside the container). And keep it clean. At least this has worked for me for years. Also, with newer -ARCH kernels, you can do non-privileged containers, so makechrootpkg should run as a ordinary user to begin with... Cheers, -- Leonid Isaev
Em dezembro 22, 2017 15:01 Leonid Isaev via arch-general escreveu:
I'm sorry for an unrelated question, but why is it really necessary to make a new container for each pkg? It seems lots of unnecessary copies (I think rsync(1) call in makechrootpkg doesn't do hardlinks)...
A new container is *spawned*, not made. You don't have lots and lots of copies.
I understand the issue about getting unlisted deps in packages, but in my experience this problem is minor. So just boot a build container and ssh in there as a non-root user (in fact, you don't even need root inside the container). And keep it clean. At least this has worked for me for years.
Keep in mind that root inside a container is not equal root outside it. But we use the build user as well inside the container.
Also, with newer -ARCH kernels, you can do non-privileged containers, so makechrootpkg should run as a ordinary user to begin with...
It already runs as an ordinary user. The container itself is ran as root, but the actual build happens as the calling user. Regards, Giancarlo Razzolini
participants (5)
-
Eli Schwartz
-
Giancarlo Razzolini
-
Leonid Isaev
-
Manuel Reimer
-
Óscar García Amor