[Ovirt-devel] root access required?

[David Lively]

I've always been a big fan of Debian's 'fakeroot' for making archives
whose files have root ownership (without actually boosting the invoking
users privileges -- so not a security hole).  And now 'fakeroot' is
available for Fedora (9, at least) via the official yum repos.

But I found one (unsurprisingly) can't 'fakeroot chroot /dir',
(where /dir (and children) are owned by the invoking user).  But I just
today (after Ben sent this) stumbled upon 'fakechroot':
    http://fakechroot.alioth.debian.org/

At first (very quick) glance, this would appear to do the trick, though
I'm not sure whether we'll hit some of the limitations described on the
man page:
    http://fakechroot.alioth.debian.org/index.cgi?ManFakechroot 

I'm also not sure what it would take to port this into a non-Debian
environment, since I haven't yet pulled down the sources.

Anyone have any experience with 'fakechroot'??

Dave

On Mon, 2008-09-08 at 11:58 -0400, Ben Guthro wrote:
> Hello,
> 
> In my endeavor to set up a build environment for our developers
> experimenting with oVirt / libvirt, I have come across a general
> dislike that the build of the ovirt managed node requires the user to
> be root.
> 
> In looking into this we have found 2 areas that I am unable to work
> out a solution for:
> 
> 1. livecd-tools must mount a filesystem image, requiring:
>     (a) losetup /dev/loopX fs-image
>         Where the user must have write access to /dev/loopX (which by
>         default is writable only by root, readable by group 'disk').
> Could be
>         worked around by changing /dev/loopX permissions (once, as
> root).
>     (b) mount /dev/loopX /mnt/point
>         Also requires root. Can be worked around with /etc/fstab entry
>         allowing user mount.
> 
> 2. 'rpm --root ...' is used to build the image.
>     --root must chroot to the specified directory to run the various
> RPM scripts.
>     chroot can't run under 'fakeroot' (AFAIK).
>     I don't know how to avoid or workaround this.
> 
> So -
> Does anyone here have any suggestions/recommended practices on how to
> go about working around these so that root access is not required?
> 
> Or - are we stuck with "that's just the way it is" for building the
> managed node image?
> 
> Ben
>