Mail archive

Re: [alpine-devel] a few abuild oddities

From: Dubiousjim <>
Date: Sun, 1 Dec 2013 18:56:59 -0500

On Sun, Dec 01, 2013 at 12:45:54PM -0500, Dubiousjim wrote:

> Second, I don't understand how abuild is acquiring sufficient
> permissions to do what it seems to be doing in these cases.
> My user belongs to the "abuild" group, but normally isn't able to even
> acquire a lock on the apk database, much less add or del packages,
> without raising privileges via sudo or su. Also, my /etc/apk/world file
> lists as:
> -rw-r--r-- 1 root root 885 Dec 1 11:58 /etc/apk/world
> However, I can be sure that sudo hasn't cached any privileges (sudo -k)
> and go into an aports directory and type `abuild -r -i pkg1` (supplying
> an appropriate package name), and then WITHOUT EVER ASKING FOR A
> PASSWORD, abuild will:
> * download and install the necessary dependencies: I assume it shouldn't
> be able to do this without privileges, although possibly the packages
> are getting installed in an overlay or some-such ... I know that
> didn't use to be the case, but I haven't kept close tabs on how the
> code has developed over the past year or so. Even if the packages
> weren't really getting installed to /, where the user running abuild
> lacks sufficient privileges, still how can abuild update
> /etc/apk/world? which one can see it does because the .makedepends-foo
> virtual package never gets deleted (see first issue above)
> * if the build completes successfully, then install the relevant local
> package, again which it shouldn't be able to do without prompting for
> a password
> Perhaps the issue here isn't with abuild, but rather with one or the
> other of fakeroot and sudo?

I've figured out the answer to this question. The answer is that we have
a binary abuild-sudo, which is installed suid, and can be invoked by
anyone in the "abuild" group (via the symlinks abuild-apk,
abuild-addgroup, and abuild-adduser) to run the corresponding commands
as root, without needing any sudo/su authentication.

Thus if your user belongs to the "abuild" group, then you can always do
all your apk-ing, with full permissions, just by invoking apk as
"abuild-apk" instead of just bare "apk".

The merits of this design may be debatable, but I'm at least relieved
that this *is* by design, and that I can now understand where and why
it's happening, and what the limits to this security opening are.
Received on Sun Dec 01 2013 - 18:56:59 UTC