On Fri, Apr 25, 2014 at 11:40:35AM +0200, Pino Toscano wrote: > Hi, > > I was investigating rh#1089100, which is about /etc/resolv.conf not > being properly SELinux-labelled. > > Basically the problem is due to /etc/resolv.conf in the guest (so > available as /sysroot/etc/resolv.conf in the appliance) being moved when > executing shell commands (eg guestfs_sh) by the daemon. > This operation involves: > a) moving away guest's /etc/resolv.conf > b) replacing it with the /etc/resolv.conf in the appliance > c) executing the actual shell command > d) moving the guest's /etc/resolv.conf back > ... but only if the network is enabled (which is by default).
Does bind-mounting /etc/resolv.conf into /sysroot not work? > So far all the ideas I found (to fix the label of /etc/resolv.conf when > --selinux-relabel is asked) were: > > 1) get the security.selinux xattr before (a), and restore it after (d). > This seems to not have worked at all, at least for me: the read xattr > is "unlabeled", which SELinux obviously refuses later; hence I > discarded it This was going to be my suggestion. Surprising there is no label on the file. > 2) closing the guestfs handle, open a new one with the network disabled > and do the relabel. > This works for me, but has the drawback to slow the process if the > relabel is asked and the network is enabled, as closing+opening an > appliance could not be that fast Yup, this sounds like a hack ... > 3) allow to switch the network on/off also when the appliance is up. > This would require to actually turn on/off the networking at > runtime, which surely cannot be done with the direct backend and most > probably neither with libvirt (but I didn't research hard on this). It probably could be done with the libvirt backend, ie. dropping or adding the network interface, but it'd be really ugly and hard. > Is anything obvious I'm missing? Can I go with solution #2? Another possibility might be to have an optional flag on guestfs_sh for enabling/disabling resolv.conf munging. Unfortunately resolv.conf munging is an implementation detail / hack, and it's not nice to expose implementation details through the API. We've regretted doing this before. I'm afraid I don't have a good answer here .. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v _______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
