Message-Id: <1386731625.3969.58128045.74D3A3D7@webmail.messagingengine.com>
From: Jim Pryor <dubiousjim@gmail.com>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: Alpine <alpine-devel@lists.alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: <20131206114150.2257d596@ncopa-desktop.alpinelinux.org>
References: <20131201174554.GB29236@zen> <20131201235659.GD29236@zen>
 <20131202142914.4438af81@ncopa-desktop.alpinelinux.org>
 <1386000265.25324.54500989.5FF25FA8@webmail.messagingengine.com>
 <20131203163409.2bfaef86@ncopa-desktop.alpinelinux.org>
 <20131204034711.GL29236@zen>
 <20131206114150.2257d596@ncopa-desktop.alpinelinux.org>
Subject: Re: [alpine-devel] a few abuild oddities
Date: Tue, 10 Dec 2013 22:13:45 -0500

On Fri, Dec 6, 2013, at 05:41 AM, Natanael Copa wrote:
> > > > 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.
> > 
> > Ok, but they don't have to be permissions to use "sudo abuild -r ..."
> > WITHOUT PASSWORD, correct? That's the behavior I expect.
> 
> I don't understand the question. Sorry.
> 
> abuild will slap you in the face if you run abuild as root (sudo abuild)
> 
> The point was that you on buildservers don't need to add user to
> sudoers (with NOPASSWD). Build servers cannot prompt for passwords.

Sorry I wasn't clear. If I'm understanding right, here is how things
stand:

One can't run abuild as root, or using "sudo abuild" (unless one
supplies the -F switch?).

One option is to add the current user to the abuild group (log out and
log back in as needed). Then abuild can do everything it needs to do,
without prompting for any passwords.

Another option is to do this:

> > > 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").

Then the user in question needs to have permissions to run the commands
abuilds wants to run in the /etc/sudoers file. If we're talking about a
build server, then those have to be NOPASSWD permissions. But if it's an
interactive machine, then the NOPASSWD permissions aren't needed, right?
Abuild will just invoke whatever you gave it as a SUDO_APK, and if that
in turn wants to demand passwords from the user, so be it. No problem
there, correct?

> The problem is actually worse than I originally thought. abuild also
> needs to create users and groups (for pkgusers/pkggroups). This means
> that if you are in 'abuild' group you can create any user or group and
> add any user to any group.
> 
> We only need the user within fakeroot so you from package() function
> can set permissions of files and dirs within the package.
> 
> To solve this, we could either create fake users for fakeroot (so
> fakeroot belives that user exists) or we would need to have a tar-fork
> that could set ownership on given files when creating the archive. That
> way, the user don't need exist on the building system.

I don't have any insights or suggestions to make about this.
-- 
dubiousjim@gmail.com



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---