On Fri, 2013-03-01 at 10:49 +0000, Richard W.M. Jones wrote:
On Fri, Mar 01, 2013 at 10:22:14AM +0000, Matthew Booth wrote:
On Thu, 2013-02-28 at 16:02 +0000, Richard W.M. Jones wrote:
From: "Richard W.M. Jones" <rjones@redhat.com>
When a disk is opened readonly, the libvirt attach-method privately creates a qcow2 overlay on top.
This commit lets that overlay get an SELinux label, and sets it to the imagelabel specified by guestfs_internal_set_libvirt_selinux_label.
The above only applies to the libvirt attach-method. --- src/launch-libvirt.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c index 318847a..b692fd6 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -133,8 +133,8 @@ static int is_custom_qemu (guestfs_h *g); static int is_blk (const char *path); static int random_chars (char *ret, size_t len); static void ignore_errors (void *ignore, virErrorPtr ignore2); -static char *make_qcow2_overlay (guestfs_h *g, const char *path, const char *format); -static int make_qcow2_overlay_for_drive (guestfs_h *g, struct drive *drv); +static char *make_qcow2_overlay (guestfs_h *g, const char *path, const char *format, const char *selinux_imagelabel); +static int make_qcow2_overlay_for_drive (guestfs_h *g, struct drive *drv, const char *selinux_imagelabel); static void drive_free_priv (void *); static void set_socket_create_context (guestfs_h *g); static void clear_socket_create_context (guestfs_h *g); @@ -235,13 +235,13 @@ launch_libvirt (guestfs_h *g, const char *libvirt_uri) * Note that appliance can be NULL if using the old-style appliance. */ if (appliance) { - params.appliance_overlay = make_qcow2_overlay (g, appliance, "raw"); + params.appliance_overlay = make_qcow2_overlay (g, appliance, "raw", NULL); if (!params.appliance_overlay) goto cleanup; }
I remain convinced that this is going to bite us at some point in the future. The fact that it works now is essentially a quirk of the default SELinux policy. I still don't understand at all how the confined guest can access the underlying appliance image, which libvirt presumably doesn't relabel.
There's no mystery. Because the appliance disk has a <shareable/> tag, libvirt labels it as Dan explains here:
https://www.redhat.com/archives/libguestfs/2013-February/msg00139.html
Actually, that doesn't clear it up. Firstly, the <shareable/> attribute uses an alternative labelling. This alternative labelling still requires support from the policy, so it remains policy-specific. Secondly, it doesn't explain if/how the backing file is relabelled. If it isn't, why is it accessible? Again, this would be a quirk of the default policy. Dan? Matt