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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/ovirt-devel/attachments/20080908/615052a7/attachment.htm>
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?The dependency on needing root is inherited from livecd-tools. So for us to remove root as a requirement for building this needs to be changed upstream. I'd start by posting questions/requests to the livecd mailing lists and see if the developers there can easily fix this. Once root is not longer required for livecd-tools, we will be able to build everything in ovirt as non-root. We've been working on some refactoring of the ovirt repositories to help reduce the requirement to build as root. But it is still required specifically for building the oVirt Appliance and the oVirt Node. The remainder of the items can be built as non-root. Look for an email with details on this from me shortly. Perry
On Mon, Sep 08, 2008 at 11:58:42AM -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.Yep, I don't much like it building as root either :-(> 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.Those are basically the same two places where I get to a roadblock.> 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?The 'mock' program gets around this by using a setuid helper todo the chroot/bind mount stuff it requires. So this lets you run it non-root, but you can't really claim it is secure against anything other than accidental user error. In the absence of other ideas that's the only option I see for the livecd tools. Its probably a fair bit of work todo this though. I'd recommend doing the builds inside a virtual machine to protect your real host from accidental/delibrate damage Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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
>