similar to: Stop the relabeling of CD images

----- Original Message ----- > From: Eric Blake <eblake@redhat.com> > To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> > Cc: libvirt-users <libvirt-users@redhat.com> > Sent: Monday, August 19, 2013 11:24 PM > Subject: Re: [libvirt-users] Stop the relabeling of CD images > So maybe this would do it: > > <source file=...> >   <seclabel

----- Original Message ----- > From: Martin Kletzander <mkletzan@redhat.com> > To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> > Cc: Eric Blake <eblake@redhat.com>; libvirt-users <libvirt-users@redhat.com> > Sent: Tuesday, August 20, 2013 6:05 PM > Subject: Re: [libvirt-users] Stop the relabeling of CD images > > On 08/20/2013 04:19 AM, Cristian

On 08/19/2013 01:51 PM, Cristian Ciupitu wrote: > Hi, > > I'm installing the operating system for my virtual machines from CD > images and I would like for libvirtd to stop relabeling the > corresponding files. Since the installation media is no big secret, I > have labeled the files with system_u:object_r:public_content_t:s0, but > libvirtd keeps changing them to

On 08/20/2013 04:19 AM, Cristian Ciupitu wrote: > ----- Original Message ----- >> From: Eric Blake <eblake@redhat.com> >> To: Cristian Ciupitu <cristian.ciupitu@yahoo.com> >> Cc: libvirt-users <libvirt-users@redhat.com> >> Sent: Monday, August 19, 2013 11:24 PM >> Subject: Re: [libvirt-users] Stop the relabeling of CD images > >> So

On Tue, Jul 14, 2020 at 6:03 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Jul 14, 2020 at 04:02:17PM +0300, Ram Lavi wrote: > > On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <berrange@redhat.com> > > wrote: > > > > > On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote: > > > > Hello all, > > > > > >

On Tue, Jul 14, 2020 at 3:33 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Tue, Jul 14, 2020 at 03:21:17PM +0300, Ram Lavi wrote: > > Hello all, > > > > tl;dr, can you point me to the point in the libvirt repo where it's > trying > > to change a tap-device's SELinux label? > > > > I am trying to create a tap device with libvirt on

libvirt version: 3.4.0 architecture: x86_64 ubuntu16.04-server hypervisor: kvm,qemu When migrate vm, I encounter error: "Migrate VM virt21 failed unsupported configuration: Unable to find security driver for model apparmor" but two host are same environment.before this error, migrate can be success. the source host seclabel configure is this : <seclabel type='dynamic'

libvirt doesn't have a concept of "session qemu" for root: https://bugzilla.redhat.com/show_bug.cgi?id=890291 When a libguestfs-using process runs as root, and libvirt runs a qemu subprocess, the qemu subprocess is run as a non-root user (typically qemu.qemu). This causes various problems, for example if we try to open a file which is readable by root but unreadable by qemu.qemu

As people may know, we frequently encounter errors caused by libvirt when running the libguestfs appliance. I wanted to find out exactly how frequently these happen and classify the errors, so I ran the 'virt-df' tool overnight 1700 times. This tool runs several parallel qemu:///session libvirt connections both creating a short-lived appliance guest. Note that I have added Cole's

On Wed, Jan 13, 2016 at 16:25:14 +0100, Martin Kletzander wrote: > On Wed, Jan 13, 2016 at 10:18:42AM +0000, Richard W.M. Jones wrote: > >As people may know, we frequently encounter errors caused by libvirt > >when running the libguestfs appliance. > > > >I wanted to find out exactly how frequently these happen and classify > >the errors, so I ran the

On Wed, Jan 13, 2016 at 04:25:14PM +0100, Martin Kletzander wrote: > For each of the kernels, libvirt labels them (with both DAC and selinux > labels), then proceeds to launching qemu. If this is done parallel, the > race is pretty obvious. Could you remind me why you couldn't use > <seclabel model='none'/> or <seclabel relabel='no'/> or something that

Previously we had assumed that when running as root, libvirt would always run qemu as a non-root user (eg. qemu.qemu), unless you modify a global configuration file (/etc/libvirt/qemu.conf). It turns out there is a little-known feature to make libvirt run qemu as root without modifying any configuration files. We have to add a <seclabel/> element to the appliance XML: <seclabel

I was going to post this as a patch, but I realize the patch is just working around an actual bug in the libvirt backend [not in libvirt]. Anyway, posting it here so we don't forget about it. Rich.

Link to version 1: https://www.redhat.com/archives/libguestfs/2013-February/thread.html#00122 Changes since version 1: - I've pushed two (of the three) code refactoring patches. The third one proved rather hard to move. - selinuxnorelabel option is no more. Instead there is a second internal API (internal_set_libvirt_selinux_norelabel_disks). - fixed bogus commit message -

Hello list, my name is Matteo, i'm new on that list. I'm working on a multitenancy platform with linux containers through libvirt on a production system with Red Hat 6.4. Every container run a separate instance of OpenSSH and Apache HTTPd and I need to give root privileges to the developers and I try to configure SELinux using svirt and MCS. I try the secmodel type dynamic and static in

On Sun, Dec 24, 2017 at 3:49 PM, Richard W.M. Jones <rjones@redhat.com> wrote: > On Sun, Dec 24, 2017 at 02:15:44PM +0200, Yaniv Kaul wrote: > > I'm copying a file into a VM using virt-copy-in - which is great, but the > > file is wrongly labeled. > > How can I fix that? > > Hi Yaniv, > > The easiest thing is to run this after doing the virt-copy-in:

I'm copying a file into a VM using virt-copy-in - which is great, but the file is wrongly labeled. How can I fix that? TIA, Y.

https://bugzilla.redhat.com/show_bug.cgi?id=912499 (especially comments 7 & 10) This patch set is the final fix so that we can access disks in use by other guests when SELinux and sVirt are enabled. Previously such disks were inaccessible because sVirt labels the disks with a random SELinux label to prevent other instances of qemu from being able to read them. So naturally the libguestfs

Hello everyone, If create a folder called "whatever" under /var, the context is: root:object_r:var_t /var/whatever/ That's expected as it is under /var. If I then change its type: chcont -t httpd_sys_content_t /var/whatever The context looks like: root:object_r:httpd_sys_content_t /var/whatever/ My question is...Shouldn't a relabeling of the filesystem change the type

Michal Prívozník <mprivozn@redhat.com> writes: > On 09/19/2018 12:39 PM, Milan Zamazal wrote: >> Hi, I'm playing with dynamic ownership and not all objects have their >> owners changed. > >> >> Is dynamic_ownership and its scope documented somewhere, besides the >> comment in qemu.conf? >> >> And what kinds of objects are handled by