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

Message ID CANcDzb_ry_wK4eUVH7Q_6Au9h+2GY_WbOvP+3We6-edGtid2+w@mail.gmail.com
State Superseded, archived
Headers show
Series [pacman-dev] Option to enable running makepkg in root | expand

Commit Message

Saul Tigh Jan. 16, 2020, 12:55 p.m. UTC
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 <jemzipx@gmail.com>
Date: Thu, 16 Jan 2020 18:58:27 +0700
Subject: Signed-off-by: Saul Tigh <jemzipx@gmail.com>

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(-)

 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

Comments

Eli Schwartz Jan. 16, 2020, 1:13 p.m. UTC | #1
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 <jemzipx@gmail.com>
> Date: Thu, 16 Jan 2020 18:58:27 +0700
> Subject: Signed-off-by: Saul Tigh <jemzipx@gmail.com>

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
>
Saul Tigh Jan. 16, 2020, 3:51 p.m. UTC | #2
> 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 <eschwartz@archlinux.org>
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 <jemzipx@gmail.com>
> > Date: Thu, 16 Jan 2020 18:58:27 +0700
> > Subject: Signed-off-by: Saul Tigh <jemzipx@gmail.com>
>
> 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 Jan. 16, 2020, 5:10 p.m. UTC | #3
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.
Saul Tigh Jan. 16, 2020, 5:42 p.m. UTC | #4
On Fri, Jan 17, 2020 at 12:10 AM Eli Schwartz <eschwartz@archlinux.org>
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 Jan. 16, 2020, 5:57 p.m. UTC | #5
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.
Saul Tigh Jan. 16, 2020, 6:10 p.m. UTC | #6
On Fri, Jan 17, 2020 at 12:57 AM Eli Schwartz <eschwartz@archlinux.org>
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 Jan. 17, 2020, 4:57 a.m. UTC | #7
On 17/1/20 4:10 am, Saul Tigh wrote:
> On Fri, Jan 17, 2020 at 12:57 AM Eli Schwartz <eschwartz@archlinux.org>
> 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 Jan. 17, 2020, 6:11 a.m. UTC | #8
On Fri, Jan 17, 2020 at 11:57 AM Allan McRae <allan@archlinux.org> 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 Jan. 17, 2020, 6:33 a.m. UTC | #9
On 17/1/20 4:11 pm, Saul Tigh wrote:
> On Fri, Jan 17, 2020 at 11:57 AM Allan McRae <allan@archlinux.org> 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

Patch

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