On Sun, Feb 01, 2009 at 10:04:09PM -0600, Clark Williams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> > Hrm, this is kind of scary, mock is trying to prevent this action? The
> > weird thing is that an error is reported that the action was not
> > allowed, yet the end result is that the file is indeed copied. So if
> > we're trying to prevent it, we're not doing a good job.
> I tried it on my laptop and the copy didn't happen. Not sure what's
> going on there.
> I went back and looked at the commit where I added the copyin/copyout
> options and the uidManager.dropPrivsForever() has always been there.
> I'm considering dropping it for --copyin (where we modify the chroot)
> but not for --copyout (where we modify the actual filesystem).
> What do you guys think?
Well, until we come up with a "real" security policy for mock, the above
suggestion sounds reasonable.
On Sun, 2009-02-01 at 10:17 -0600, Clark Williams wrote:
> Jesse is having an issue with --copyin; he's getting a permission
> denied when trying to copy the system /etc/hosts to the
> chroot /etc/hosts. This is due to the uidManager.dropPrivsForever()
> near the top of the --copyin logic block. My question is, do we need to
> drop privs there? Seems kinda crippling to --copyin if you can only
> copy stuff to /tmp or the homedir in the chroot.
> Or is allowing modification of the chroot environment a security issue
> we're not willing to live with? Can we check to see if mock has been
> kicked off as root (or does the pam helper logic neuter that)?
Hrm, this is kind of scary, mock is trying to prevent this action? The
weird thing is that an error is reported that the action was not
allowed, yet the end result is that the file is indeed copied. So if
we're trying to prevent it, we're not doing a good job.
Fedora -- Freedom² is a feature!