Mail archive

Re: [alpine-devel] a few abuild oddities

From: Natanael Copa <>
Date: Tue, 3 Dec 2013 16:34:09 +0100

On Mon, 02 Dec 2013 11:04:25 -0500
Jim Pryor <> wrote:

> On Mon, Dec 2, 2013, at 08:29 AM, Natanael Copa wrote:
> > One thing we could do to improve the security a bit is to ban the
> > --allow-untrusted option with the suid abuild-apk. That would allow the
> > users in abuild group to install signed packages only. Adding the user
> > to 'abuild' group and the users key to /etc/apk/keys would then be
> > equivalent as give full root access.
> I do think this would be a good improvement, if only for people who put
> users in the abuild group without fully understanding the consequences.
> In practice, though, anyone who knows what they're doing is going to
> also put a key in /etc/apk/keys, and then any vulnerabilities in that
> account will give full root access.

Ok. I will look into this.
> Is it possible to use abuild for the full range of activities without
> being in the abuild group? Do we just prompt with sudo or su in those
> cases when needed? In that case the security-conscious solution will
> just be don't add your users to the "abuild" group. The costs and
> benefits of this would just need to be more clearly documented.

You need either be in abuild group or have sudo permissions to use
abuild -r for letting abuild install the deps for you.

To use sudo instead of abuild-apk you can set SUDO_APK="sudo apk"
in /etc/abuild.conf (or just export SUDO_APK="sudo apk").

You can still build packages with abuild without needing sudo but then
all the dependencies needs to be installed already:
  SUDO_APK=apk abuild

The motivation behind abuild group was to make it convenient to set up
a build server. Might be we want change the default back to sudo.


Received on Tue Dec 03 2013 - 16:34:09 UTC