Discussion summary: Mock security

[David Smith]

On Wed, 2006-06-07 at 10:20 -0500, David Smith wrote:
> On Wed, 2006-06-07 at 11:13 -0400, Jeremy Katz wrote:

... stuff deleted ...

> > What if, instead, it chrooted + changed to the mockbuild user?  Would 
> > that break your usage case?
> > 
> > Jeremy
> 
> Hmm, it might.  Actually we currently do the equivalent of
> 
> # mock chroot "/sbin/runuser - mockbuild -c "{command}""
> 
> on most of the commands we run (but not all).  I'll see if we can't run
> as the mockbuild user all the time and let you know (probably tomorrow).

I'm not sure if the results of my investigations are still needed at
this point (with all the other ideas floating around), but here they are
anyway.

In general running as mockbuild worked, except for a couple of cases:

1) Annoying problem.  We copy a few files into the chroot, then chown
them to the mockbuild user.  Originally it was done like this:

# sudo cp foo /var/lib/mock/{chroot_name}/root/{whatever}
# mock chroot chown mockbuild.mockbuild /{whatever}

Obviously the mockbuild user can't run chown, so I tried to just do it
with sudo.

# sudo cp foo /var/lib/mock/{chroot_name}/root/{whatever}
# sudo chown
mockbuild.mockbuild /var/lib/mock/{chroot_name}/root/{whatever}

but of course the problem is that I don't know the mockbuild UID/GID in
the host OS.  I just hardcoded them for now and went on.

2) Real problem.  I could do most other things as the mockbuild user,
but one of the things we do is build up what we call a sysroot inside
the chroot.  The sysroot has its own RPM database (since it is a
different architecture than the chroot).  Unfortunately, when writing to
the rpm database you have to be root.  I don't see any good way around
this one.

-- 
David Smith
dsmith at redhat.com
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)