2:51 p.m.
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 system_u:object_r:svirt_image_t:s0. It
also changes the ownership to qemu:qemu. This means that I can not make
the files immutable (chattr +i).
The XML dump of the machine looks like this :
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source
file='/mnt/extra/Software/Linux/Fedora/Fedora-Live-Desktop-x86_64-19/Fedora-Live-Desktop-x86_64-19-1.iso'>
<seclabel relabel='no'/>
</source>
<target dev='hdc' bus='ide'/>
<readonly/>
<shareable/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
I am using libvirt-daemon-1.1.1-2.fc19.x86_64. You might also find
interesting bug #568935 [1].
So how do I stop libvirtd from changing the permissions of the CD
images?
Thank you,
Cristian Ciupitu
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=568935
3:24 p.m.
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 system_u:object_r:svirt_image_t:s0. It
also changes the ownership to qemu:qemu. This means that I can not make
the files immutable (chattr +i).
Caveat - this is not something I have tried myself, so try it out, and
feel free to post back if it works or doesn't work for your case.
The XML dump of the machine looks like this :
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source
file='/mnt/extra/Software/Linux/Fedora/Fedora-Live-Desktop-x86_64-19/Fedora-Live-Desktop-x86_64-19-1.iso'>
<seclabel relabel='no'/>
Hmm, the documentation at http://libvirt.org/formatdomain.html#seclabel
is a bit stale; the last paragraph mentions that you can apply
per-<disk> seclabel overrides, but fails to mention that model='...' is
valid in that XML.
Since you already know what label you want, it might be worth trying to
force that particular label instead of requesting no relabel, as in:
<source file=...>
<seclabel model='selinux' relabel='yes'>
<label>system_u:object_r:public_content_t:s0</label>
</seclabel>
</source>
so that might get libvirt to stop doing the SELinux relabel dance on
your .iso file. Then again, I'm not sure if that will prevent libvirt
from trying to "un-label" the device when your guest shuts down.
Then there's the question of the chown, which is caused by the DAC
driver rather than the SELinux driver. So maybe this would do it:
<source file=...>
<seclabel model='selinux' relabel='no'/>
<seclabel model='dac' relabel='no'/>
</source>
I wouldn't be surprised if we need to patch our docs to be more clear
about this. I also know that there has been talk of a patch for
teaching libvirt how to restore labels to their original state, instead
of the current problem of "restoring" labels to a single default setting
(even where that does not match the original setting).
I'm also not sure why you think to resort to chattr +i, but if using
that causes libvirt heartburn, maybe we have a bug to fix to be more
tolerant of failed label attempts due to chattr.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9:19 p.m.
----- Original Message -----
From: Eric Blake <eblake(a)redhat.com>
To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
Cc: libvirt-users <libvirt-users(a)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 model='selinux' relabel='no'/>
<seclabel model='dac' relabel='no'/>
</source>
I've just tried it and the SELinux label is not changed anymore, but the
ownership is still changed to qemu:qemu.
I'm also not sure why you think to resort to chattr +i, but if
using
that causes libvirt heartburn, maybe we have a bug to fix to be more
tolerant of failed label attempts due to chattr.
I resorted to `chattr +i` because I got tired of libvirtd messing with
my files even if it wasn't required. The official versions of libvirtd
from Fedora 18 or 19 used to complain about not being able to change the
files, but the current bleeding edge version hasn't complained (with the
XML config from above).
To sum it up, SELinux - solved, DAC - not (yet).
Thank you,
Cristian Ciupitu
10:05 a.m.
On 08/20/2013 04:19 AM, Cristian Ciupitu wrote:
----- Original Message -----
> From: Eric Blake <eblake(a)redhat.com>
> To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
> Cc: libvirt-users <libvirt-users(a)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 model='selinux' relabel='no'/>
> <seclabel model='dac' relabel='no'/>
> </source>
I've just tried it and the SELinux label is not changed anymore, but the
ownership is still changed to qemu:qemu.
> I'm also not sure why you think to resort to chattr +i, but if using
> that causes libvirt heartburn, maybe we have a bug to fix to be more
> tolerant of failed label attempts due to chattr.
I resorted to `chattr +i` because I got tired of libvirtd messing with
my files even if it wasn't required. The official versions of libvirtd
from Fedora 18 or 19 used to complain about not being able to change the
files, but the current bleeding edge version hasn't complained (with the
XML config from above).
To sum it up, SELinux - solved, DAC - not (yet).
I played with it earlier, but I'm not sure which settings we use when.
This is just a "possible workaround", even though it might look like
it's doing something else. Anyway, If I'm not mistaken, adding a
<shareable/> into the <disk> element should stop all relabeling.
Correct me if I'm wrong and post your findings, I'll try how relabel
works for DAC with upstream in the meantime.
Martin
3:17 p.m.
----- Original Message -----
From: Martin Kletzander <mkletzan(a)redhat.com>
To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
Cc: Eric Blake <eblake(a)redhat.com>; libvirt-users <libvirt-users(a)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 Ciupitu wrote:
> ----- Original Message -----
>> From: Eric Blake <eblake(a)redhat.com>
>> To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
>> Cc: libvirt-users <libvirt-users(a)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 model='selinux' relabel='no'/>
>> <seclabel model='dac' relabel='no'/>
>> </source>
>
> I've just tried it and the SELinux label is not changed anymore, but
> the ownership is still changed to qemu:qemu.
>
>> I'm also not sure why you think to resort to chattr +i, but if using
>> that causes libvirt heartburn, maybe we have a bug to fix to be more
>> tolerant of failed label attempts due to chattr.
>
> I resorted to `chattr +i` because I got tired of libvirtd messing with
> my files even if it wasn't required. The official versions of libvirtd
> from Fedora 18 or 19 used to complain about not being able to change the
> files, but the current bleeding edge version hasn't complained (with the
> XML config from above).
>
> To sum it up, SELinux - solved, DAC - not (yet).
>
I played with it earlier, but I'm not sure which settings we use when.
This is just a "possible workaround", even though it might look like
it's doing something else. Anyway, If I'm not mistaken, adding a
<shareable/> into the <disk> element should stop all relabeling.
Correct me if I'm wrong and post your findings, I'll try how relabel
works for DAC with upstream in the meantime.
<shareable/> didn't work for me. This is what I currently have:
# virsh dumpxml test
...
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source
file='/mnt/extra/Software/Linux/Fedora/Fedora-Live-Desktop-x86_64-19/Fedora-Live-Desktop-x86_64-19-1.iso'>
<seclabel model='selinux' relabel='no'/>
</source>
<target dev='hdc' bus='ide'/>
<readonly/>
<shareable/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
...
And this is what happens:
# ls -lZ Fedora-Live-Desktop-x86_64-19-1.iso
-r--r--r--. root root system_u:object_r:public_content_t:s0
Fedora-Live-Desktop-x86_64-19-1.iso
# virsh start test
Domain test started
# ls -lZ Fedora-Live-Desktop-x86_64-19-1.iso
-r--r--r--. qemu qemu system_u:object_r:public_content_t:s0
Fedora-Live-Desktop-x86_64-19-1.iso
Adding <seclabel model='dac' relabel='no'/> under <source>
doesn't make
a difference.
Kind regards,
Cristian Ciupitu
12:52 a.m.
On Tue 20 Aug 2013 10:17:19 PM CEST, Cristian Ciupitu wrote:
----- Original Message -----
> From: Martin Kletzander <mkletzan(a)redhat.com>
> To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
> Cc: Eric Blake <eblake(a)redhat.com>; libvirt-users
<libvirt-users(a)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 Ciupitu wrote:
>> ----- Original Message -----
>>> From: Eric Blake <eblake(a)redhat.com>
>>> To: Cristian Ciupitu <cristian.ciupitu(a)yahoo.com>
>>> Cc: libvirt-users <libvirt-users(a)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 model='selinux' relabel='no'/>
>>> <seclabel model='dac' relabel='no'/>
>>> </source>
>>
>> I've just tried it and the SELinux label is not changed anymore, but
>> the ownership is still changed to qemu:qemu.
>>
>>> I'm also not sure why you think to resort to chattr +i, but if using
>>> that causes libvirt heartburn, maybe we have a bug to fix to be more
>>> tolerant of failed label attempts due to chattr.
>>
>> I resorted to `chattr +i` because I got tired of libvirtd messing with
>> my files even if it wasn't required. The official versions of libvirtd
>> from Fedora 18 or 19 used to complain about not being able to change the
>> files, but the current bleeding edge version hasn't complained (with the
>> XML config from above).
>>
>> To sum it up, SELinux - solved, DAC - not (yet).
>>
>
> I played with it earlier, but I'm not sure which settings we use when.
> This is just a "possible workaround", even though it might look like
> it's doing something else. Anyway, If I'm not mistaken, adding a
> <shareable/> into the <disk> element should stop all relabeling.
> Correct me if I'm wrong and post your findings, I'll try how relabel
> works for DAC with upstream in the meantime.
<shareable/> didn't work for me. This is what I currently have:
# virsh dumpxml test
...
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source
file='/mnt/extra/Software/Linux/Fedora/Fedora-Live-Desktop-x86_64-19/Fedora-Live-Desktop-x86_64-19-1.iso'>
<seclabel model='selinux' relabel='no'/>
</source>
<target dev='hdc' bus='ide'/>
<readonly/>
<shareable/>
<address type='drive' controller='0' bus='1'
target='0' unit='0'/>
</disk>
...
And this is what happens:
# ls -lZ Fedora-Live-Desktop-x86_64-19-1.iso
-r--r--r--. root root system_u:object_r:public_content_t:s0
Fedora-Live-Desktop-x86_64-19-1.iso
# virsh start test
Domain test started
# ls -lZ Fedora-Live-Desktop-x86_64-19-1.iso
-r--r--r--. qemu qemu system_u:object_r:public_content_t:s0
Fedora-Live-Desktop-x86_64-19-1.iso
Adding <seclabel model='dac' relabel='no'/> under <source>
doesn't make
a difference.
It doesn't and it should. I looked at the code and dac model doesn't
support the 'relabel' attribute at all (or anything that stops
relabeling, really). Since we don't mention that 'relabel' is supported
only for selinux security driver, feel free to spin up a bug with the
info you have. The relabel support is fairly simple, but I'll try to go
through the code and see whether there's something more that might be
fixed altogether.
Martin
3992
days inactive
3994
days old
5 comments
3 participants
participants (3)
-
Cristian Ciupitu -
Eric Blake -
Martin Kletzander