[pacman-dev] makepkg: privilege management utility? twice

Loui Chang louipc.ist at gmail.com
Thu Jun 17 21:18:33 EDT 2010


On Fri 18 Jun 2010 09:37 +1000, Allan McRae wrote:
> On 18/06/10 09:12, Loui Chang wrote:
> >On Fri 18 Jun 2010 08:19 +1000, Allan McRae wrote:
> >>On 18/06/10 01:09, Loui Chang wrote:
> >>>Why not just take sudo and asroot out of the equation and treat makepkg
> >>>as a real non-handholding executable?
> >>
> >>What do you mean?   Remove automatic dependency installation or
> >>require the entire thin to be run as root?
> >
> >Enable the entire thing to be run as any user.
> >
> >A user does not necessarily need to be called 'root' to have package
> >manager privileges, nor do they need to be 'root' to have superuser
> >privileges, so why do we need a special flag for when the user does
> >happen to be 'root'?
> >
> >I think a user should arrange those himself, rather than having makepkg
> >assume that he wants to become root via sudo. If the user hasn't
> >previously arranged the privs, then makepkg dependency installation
> >should fail.
> >
> >In my opinion any use of sudo, and any restrictions on root in makepkg
> >should be removed. If you're keen to this idea I could provide some
> >patches.
>
> I still am not sure where you are going with this...

What I'm essentially saying is that makepkg shouldn't be the one
managing privileges. It should be the users.

> 1) pacman requires you to be root to install packages (or at least
> UID=0 I think)
> > pacman -S pacman
> error: you cannot perform this operation unless you are root.
>
> 2) Doing the actual packaging as root is dangerous, especially if
> you have "make install" by accident in your PKGBUILD.  Or, as does
> happen, the software has a shitty Makefile and ignores DESTDIR for
> part of the installation (for this reason --asroot is not being
> removed).
>
> So we have conflicting needs within makepkg.  root to install,
> non-root to build.  When makepkg needs to install dependency
> packages, it checks if sudo is an option and if not falls back to
> using "su -c", and if that fails it gives up.  Are you proposing
> that it just gives up straight away and not attempt privilege
> escalation?

Yes, I am proposing that.

You can always drop to more restricted permissions to build if you are
a worried superuser. It's an admin's duty to understand these
precautions isn't it?



More information about the pacman-dev mailing list