[pacman-dev] [PATCH] Option to enable running makepkg in root

newer
[pacman-dev] [PATCH] makepkg: make...

older
[pacman-dev] [PATCH v2] Option to...

Saul Tigh

16 Jan 2020 16 Jan '20

1:55 p.m.

Dear Pacman devs, Although running makepkg in root is frowned upon and considered dangerous, there are circumstances that one might need to do so. For example, during the bootstrap process of building my own toy gnu/linux distro (which uses pacman/makepkg), I have to run makepkg in root. I have added an option called "ALLOWROOT" to makepkg which when is set to 1 enables running makepkg in root. This option is disable by default and wouldn't cause any issue for the average user of pacman and makepkg. This is my first patch for pacman so criticism is welcome and please let me know how to improve it.

...

From def5a1cae3513e75aa6447a27f3f22a207ffdc61 Mon Sep 17 00:00:00 2001 From: Saul Tigh Date: Thu, 16 Jan 2020 18:58:27 +0700 Subject: Signed-off-by: Saul Tigh

Although running makepkg in root is frowned upon, there are circumstances that one might need to do so. For example, during the bootstrap process of building his toy gnu/linux distro, the author of this patch needs to run makepkg in root. This option is disable by default. It can be enable by setting 'ALLOWROOT' in makepkg to 1. --- scripts/makepkg.sh.in | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index ca3e7459..b2cd8ee4 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -79,6 +79,7 @@ SIGNPKG='' SPLITPKG=0 SOURCEONLY=0 VERIFYSOURCE=0 +ALLOWROOT=0 if [[ -n $SOURCE_DATE_EPOCH ]]; then REPRODUCIBLE=1 @@ -1175,9 +1176,13 @@ fi if (( ! INFAKEROOT )); then if (( EUID == 0 )); then - error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ -catastrophic damage to your system.")" "makepkg" - exit $E_ROOT + if (( ALLOWROOT )); then + plain "Running as root is not recommended. Proceed with caution." + else + error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ + catastrophic damage to your system.")" "makepkg" + exit $E_ROOT + fi fi else if [[ -z $FAKEROOTKEY ]]; then @@ -1352,6 +1357,10 @@ if (( SOURCEONLY )); then check_source_integrity all cd_safe "$startdir" + # allow makepkg to run in root + if (( ALLOWROOT )); then + unset FAKEROOTKEY + fi enter_fakeroot if [[ $SIGNPKG = 'y' ]]; then -- 2.20.1

Show replies by date

Eli Schwartz

16 Jan 16 Jan

2:13 p.m.

On 1/16/20 7:55 AM, Saul Tigh wrote:

...

Dear Pacman devs,

Although running makepkg in root is frowned upon and considered dangerous, there are circumstances that one might need to do so. For example, during the bootstrap process of building my own toy gnu/linux distro (which uses pacman/makepkg), I have to run makepkg in root.

Hmm, why is this though? Shouldn't the system which you are bootstrapping from be just as capable of using a delegated build user?

...

I have added an option called "ALLOWROOT" to makepkg which when is set to 1 enables running makepkg in root. This option is disable by default and wouldn't cause any issue for the average user of pacman and makepkg. This is my first patch for pacman so criticism is welcome and please let me know how to improve it.

If using this requires patching makepkg anyway, what's the advantage over just using a custom patch for the whole thing?

...

From def5a1cae3513e75aa6447a27f3f22a207ffdc61 Mon Sep 17 00:00:00 2001 From: Saul Tigh Date: Thu, 16 Jan 2020 18:58:27 +0700 Subject: Signed-off-by: Saul Tigh

Patches should be sent via git-send-email, BTW.

...

Although running makepkg in root is frowned upon, there are circumstances that one might need to do so. For example, during the bootstrap process of building his toy gnu/linux distro, the author of this patch needs to run makepkg in root. This option is disable by default. It can be enable by setting 'ALLOWROOT' in makepkg to 1. --- scripts/makepkg.sh.in | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index ca3e7459..b2cd8ee4 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -79,6 +79,7 @@ SIGNPKG='' SPLITPKG=0 SOURCEONLY=0 VERIFYSOURCE=0 +ALLOWROOT=0

if [[ -n $SOURCE_DATE_EPOCH ]]; then REPRODUCIBLE=1 @@ -1175,9 +1176,13 @@ fi

if (( ! INFAKEROOT )); then if (( EUID == 0 )); then - error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ -catastrophic damage to your system.")" "makepkg" - exit $E_ROOT + if (( ALLOWROOT )); then + plain "Running as root is not recommended. Proceed with caution." + else + error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ + catastrophic damage to your system.")" "makepkg" + exit $E_ROOT + fi fi else if [[ -z $FAKEROOTKEY ]]; then @@ -1352,6 +1357,10 @@ if (( SOURCEONLY )); then check_source_integrity all cd_safe "$startdir"

+ # allow makepkg to run in root + if (( ALLOWROOT )); then + unset FAKEROOTKEY + fi enter_fakeroot

if [[ $SIGNPKG = 'y' ]]; then

-- Eli Schwartz Bug Wrangler and Trusted User

Saul Tigh

4:51 p.m.

...

Hmm, why is this though? Shouldn't the system which you are bootstrapping from be just as capable of using a delegated build user?

The bootstrap process has two stages. The first stage is done with a delegated build user on the host system and the second stage is done inside chroot and has to be done as root user (very similar to chapter six of the lfs book). It is while inside this chroot as root user that makepg has to compile and build the packages. As I understand it, the bootstrap process is quite different than the way arch linux is constructed.

...

If using this requires patching makepkg anyway, what's the advantage over just using a custom patch for the whole thing?

I believe it is better to have more options available to the power user. I do realize that pacman is mainly designed for archlinux/derivatives which might not benefit from this feature but it is good to cover corner cases such as this that might benefit other users as well. Personally, I really benefit from this feature and would appreciate it if it is included in the mainstream version of pacman. This feature does not change the default behavior of makepkg/pacman and is only enabled if the ALLOWROOT option is enabled.

...

Patches should be sent via git-send-email, BTW. I apologize for this. Just part of being a noob really. I can resubmit using git-send-email.

On Thu, Jan 16, 2020 at 8:14 PM Eli Schwartz wrote:

...

On 1/16/20 7:55 AM, Saul Tigh wrote:

...
Dear Pacman devs,

Although running makepkg in root is frowned upon and considered dangerous, there are circumstances that one might need to do so. For example, during the bootstrap process of building my own toy gnu/linux distro (which uses pacman/makepkg), I have to run makepkg in root.

Hmm, why is this though? Shouldn't the system which you are bootstrapping from be just as capable of using a delegated build user?

...
I have added an option called "ALLOWROOT" to makepkg which when is set to 1 enables running makepkg in root. This option is disable by default and wouldn't cause any issue for the average user of pacman and makepkg. This is my first patch for pacman so criticism is welcome and please let me know how to improve it.

If using this requires patching makepkg anyway, what's the advantage over just using a custom patch for the whole thing?

...
From def5a1cae3513e75aa6447a27f3f22a207ffdc61 Mon Sep 17 00:00:00 2001 From: Saul Tigh Date: Thu, 16 Jan 2020 18:58:27 +0700 Subject: Signed-off-by: Saul Tigh

Patches should be sent via git-send-email, BTW.

...
Although running makepkg in root is frowned upon, there are circumstances that one might need to do so. For example, during the bootstrap process of building his toy gnu/linux distro, the author of this patch needs to run makepkg in root. This option is disable by default. It can be enable by setting 'ALLOWROOT' in makepkg to 1. --- scripts/makepkg.sh.in | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index ca3e7459..b2cd8ee4 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -79,6 +79,7 @@ SIGNPKG='' SPLITPKG=0 SOURCEONLY=0 VERIFYSOURCE=0 +ALLOWROOT=0

if [[ -n $SOURCE_DATE_EPOCH ]]; then REPRODUCIBLE=1 @@ -1175,9 +1176,13 @@ fi

if (( ! INFAKEROOT )); then if (( EUID == 0 )); then - error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ -catastrophic damage to your system.")" "makepkg" - exit $E_ROOT + if (( ALLOWROOT )); then + plain "Running as root is not recommended. Proceed with caution." + else + error "$(gettext "Running %s as root is not allowed as it can cause permanent,\n\ + catastrophic damage to your system.")" "makepkg" + exit $E_ROOT + fi fi else if [[ -z $FAKEROOTKEY ]]; then @@ -1352,6 +1357,10 @@ if (( SOURCEONLY )); then check_source_integrity all cd_safe "$startdir"

+ # allow makepkg to run in root + if (( ALLOWROOT )); then + unset FAKEROOTKEY + fi enter_fakeroot

if [[ $SIGNPKG = 'y' ]]; then

-- Eli Schwartz Bug Wrangler and Trusted User

Eli Schwartz

6:10 p.m.

On 1/16/20 10:51 AM, Saul Tigh wrote:

...

...
Hmm, why is this though? Shouldn't the system which you are bootstrapping from be just as capable of using a delegated build user?

The bootstrap process has two stages. The first stage is done with a delegated build user on the host system and the second stage is done inside chroot and has to be done as root user (very similar to chapter six of the lfs book). It is while inside this chroot as root user that makepg has to compile and build the packages. As I understand it, the bootstrap process is quite different than the way arch linux is constructed.

Do you mean there is no user account management set up yet? If it's just about switching users, util-linux "runuser" can let you run makepkg with a different user ID.

...

...
If using this requires patching makepkg anyway, what's the advantage over just using a custom patch for the whole thing?

I believe it is better to have more options available to the power user. I do realize that pacman is mainly designed for archlinux/derivatives which might not benefit from this feature but it is good to cover corner cases such as this that might benefit other users as well. Personally, I really benefit from this feature and would appreciate it if it is included in the mainstream version of pacman. This feature does not change the default behavior of makepkg/pacman and is only enabled if the ALLOWROOT option is enabled.

Wouldn't it make more sense in that case to add a build system switch e.g. meson -Dmakepkg-asroot=enabled? I'm concerned about including a codepath that doesn't do anything unless you know it exists and patch the source to use it. -- Eli Schwartz Bug Wrangler and Trusted User

Saul Tigh

6:42 p.m.

On Fri, Jan 17, 2020 at 12:10 AM Eli Schwartz wrote:

...

On 1/16/20 10:51 AM, Saul Tigh wrote:

...
Do you mean there is no user account management set up yet? If it's just about switching users, util-linux "runuser" can let you run makepkg with a different user ID.

I re-submitted the patch with 'git send-email' to comply with the rules. As to user management, none exists at that stage. The system is absolutely bare however I think the root privilege is needed at that stage and is not just a question of changing user ID.

...

...
Wouldn't it make more sense in that case to add a build system switch e.g. meson -Dmakepkg-asroot=enabled? I'm concerned about including a codepath that doesn't do anything unless you know it exists and patch the source to use it.

That is a valid point. I have to do more research about meson build system as I'm not familiar with it much and will try to re-submit a new patch with your suggestion. Has pacman moved away from autotools completely and do things with meson?

Eli Schwartz

6:57 p.m.

On 1/16/20 12:42 PM, Saul Tigh wrote:

...

I re-submitted the patch with 'git send-email' to comply with the rules.

Thanks, your v2 patch no longer returns an error claiming it is corrupted. :)

...

As to user management, none exists at that stage. The system is absolutely bare however I think the root privilege is needed at that stage and is not just a question of changing user ID.

...
...
Wouldn't it make more sense in that case to add a build system switch e.g. meson -Dmakepkg-asroot=enabled? I'm concerned about including a codepath that doesn't do anything unless you know it exists and patch the source to use it.

That is a valid point. I have to do more research about meson build system as I'm not familiar with it much and will try to re-submit a new patch with your suggestion. Has pacman moved away from autotools completely and do things with meson?

Most likely you'd want to take a look at build-aux/edit-script.sh.in, and the "substs" dictionary of replacements in meson.build -- you can add options to meson_options.txt autotools is still supported, and I'd advise adding options to both meson and autotools -- the plan is to deprecate autotools soon, but until it's actually removed, we should probably try to make them both behave the same. :D Feel free to ask any questions about implementing changes in meson. -- Eli Schwartz Bug Wrangler and Trusted User

Saul Tigh

7:10 p.m.

On Fri, Jan 17, 2020 at 12:57 AM Eli Schwartz wrote:

...

Thanks, your v2 patch no longer returns an error claiming it is corrupted. :)

Glad to hear it ;) I'm very new to this whole submitting patch via git process so please bear with me.

...

Most likely you'd want to take a look at build-aux/edit-script.sh.in, and the "substs" dictionary of replacements in meson.build -- you can add options to meson_options.txt

autotools is still supported, and I'd advise adding options to both meson and autotools -- the plan is to deprecate autotools soon, but until it's actually removed, we should probably try to make them both behave the same. :D

Feel free to ask any questions about implementing changes in meson.

Thanks a lot. I will get down to work and re-submit a new patch once it is ready. The support in pacman community is amazing ;)

Allan McRae

17 Jan 17 Jan

5:57 a.m.

On 17/1/20 4:10 am, Saul Tigh wrote:

...

On Fri, Jan 17, 2020 at 12:57 AM Eli Schwartz wrote:

...
Thanks, your v2 patch no longer returns an error claiming it is corrupted. :)

Glad to hear it ;) I'm very new to this whole submitting patch via git process so please bear with me.

...
Most likely you'd want to take a look at build-aux/edit-script.sh.in, and the "substs" dictionary of replacements in meson.build -- you can add options to meson_options.txt

autotools is still supported, and I'd advise adding options to both meson and autotools -- the plan is to deprecate autotools soon, but until it's actually removed, we should probably try to make them both behave the same. :D

Feel free to ask any questions about implementing changes in meson.

Thanks a lot. I will get down to work and re-submit a new patch once it is ready. The support in pacman community is amazing ;)

Note... there was an --as-root option not that long ago. It was removed for valid reasons. I will not be accepting a patch that adds this back in. Particularly given I see no justification. I have bootstrapped a LFS build using pacman as a package manager and used a dedicated build user throughout. Allan

Saul Tigh

7:11 a.m.

On Fri, Jan 17, 2020 at 11:57 AM Allan McRae wrote:

...

Note... there was an --as-root option not that long ago. It was removed for valid reasons. I will not be accepting a patch that adds this back in. Particularly given I see no justification. I have bootstrapped a LFS build using pacman as a package manager and used a dedicated build user throughout.

Allan

I know this is perhaps not the right place, but would appreciate it if you could point out how you managed to achieve bootstrapping LFS build with a dedicated build user (or maybe share the scripts please).

Allan McRae

7:33 a.m.

On 17/1/20 4:11 pm, Saul Tigh wrote:

...

On Fri, Jan 17, 2020 at 11:57 AM Allan McRae wrote:

...
Note... there was an --as-root option not that long ago. It was removed for valid reasons. I will not be accepting a patch that adds this back in. Particularly given I see no justification. I have bootstrapped a LFS build using pacman as a package manager and used a dedicated build user throughout.

Allan

I know this is perhaps not the right place, but would appreciate it if you could point out how you managed to achieve bootstrapping LFS build with a dedicated build user (or maybe share the scripts please).

It was quite a few years ago, but a quick google search found this: https://github.com/benvd/lfs-pacman Looks very similar to what I did. I don't know what issue you are running into, so can't help directly. And it is not particularly pacman related... Allan

1623

Age (days ago)

1624

Last active (days ago)

List overview

Download

9 comments

3 participants

participants (3)

Allan McRae
Eli Schwartz
Saul Tigh

[pacman-dev] [PATCH] Option to enable running makepkg in root

tags

participants (3)