Bug 1189275 - Resuming a block device (dm) changes its selinux context
Summary: Resuming a block device (dm) changes its selinux context
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: pre-dev-freeze
: ---
Assignee: Michal Privoznik
QA Contact: yafu
URL:
Whiteboard:
: 1265024 (view as bug list)
Depends On: 1147910 1265024
Blocks: 1122979 1147923 1148013 RHV4.1PPC
TreeView+ depends on / blocked
 
Reported: 2015-02-04 20:50 UTC by Nir Soffer
Modified: 2019-04-28 13:42 UTC (History)
46 users (show)

Fixed In Version: libvirt-3.1.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1147910
Environment:
Last Closed: 2017-08-01 17:06:41 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description Nir Soffer 2015-02-04 20:50:09 UTC
+++ This bug was initially created as a clone of Bug #1147910 +++

Description of problem:
When a dm is resumed systemd-udevd changes its selinux context:

# dmsetup suspend 539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6

# ls -Z /dev/dm-4
brw-rw----. vdsm qemu system_u:object_r:svirt_image_t:s0 /dev/dm-4

# dmsetup resume 539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6

# ls -Z /dev/dm-4
brw-rw----. vdsm qemu system_u:object_r:fixed_disk_device_t:s0 /dev/dm-4

Version-Release number of selected component (if applicable):
systemd-208-22.fc20.x86_64

How reproducible:
100%

Steps to Reproduce:
1. start a VM on a dm device using libvirt
2. refresh the dm (needed for example after a resize, anyway dmsetup suspend/resume are enough to trigger the issue)

Actual results:
The VM is paused (or its IO fails, depending on the VM config) since it can't write to the dm anymore.

Expected results:
The VM should keep running (no IO failures) even after a refresh of the dm.

Additional info:

Debug + strace of /usr/lib/systemd/systemd-udevd:

RUN '/usr/sbin/dmsetup udevcomplete $env{DM_COOKIE}' /usr/lib/udev/rules.d/95-dm-notify.rules:12
handling device node '/dev/dm-4', devnum=b253:4, mode=0660, uid=36, gid=107
preserve permissions /dev/dm-4, 060660, uid=36, gid=107
[pid 23728] lsetxattr("/dev/dm-4", "security.selinux", "system_u:object_r:fixed_disk_device_t:s0", 41, 0) = 0
preserve already existing symlink '/dev/block/253:4' to '../dm-4'
[pid 23728] lsetxattr("/dev/block/253:4", "security.selinux", "system_u:object_r:device_t:s0", 30, 0) = 0
found 'b253:4' claiming '/run/udev/links/\x2f539cfcda-bc30-4e35-845e-888a58229e52\x2f1d84a603-1a4a-461a-af1e-c1541f5f12b6'
creating link '/dev/539cfcda-bc30-4e35-845e-888a58229e52/1d84a603-1a4a-461a-af1e-c1541f5f12b6' to '/dev/dm-4'
preserve already existing symlink '/dev/539cfcda-bc30-4e35-845e-888a58229e52/1d84a603-1a4a-461a-af1e-c1541f5f12b6' to '../dm-4'
[pid 23728] lsetxattr("/dev/539cfcda-bc30-4e35-845e-888a58229e52/1d84a603-1a4a-461a-af1e-c1541f5f12b6", "security.selinux", "system_u:object_r:device_t:s0", 30, 0) = 0
found 'b253:4' claiming '/run/udev/links/\x2fdisk\x2fby-id\x2fdm-name-539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6'
creating link '/dev/disk/by-id/dm-name-539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6' to '/dev/dm-4'
preserve already existing symlink '/dev/disk/by-id/dm-name-539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6' to '../../dm-4'
[pid 23728] lsetxattr("/dev/disk/by-id/dm-name-539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6", "security.selinux", "system_u:object_r:device_t:s0", 30, 0) = 0
found 'b253:4' claiming '/run/udev/links/\x2fdisk\x2fby-id\x2fdm-uuid-LVM-RBGwiMghcHZfY95VC5SeHFT20xaKJp1EIOBOK3Ejxq1FTfDKI4HngfgKoihn8G3p'
creating link '/dev/disk/by-id/dm-uuid-LVM-RBGwiMghcHZfY95VC5SeHFT20xaKJp1EIOBOK3Ejxq1FTfDKI4HngfgKoihn8G3p' to '/dev/dm-4'
preserve already existing symlink '/dev/disk/by-id/dm-uuid-LVM-RBGwiMghcHZfY95VC5SeHFT20xaKJp1EIOBOK3Ejxq1FTfDKI4HngfgKoihn8G3p' to '../../dm-4'
[pid 23728] lsetxattr("/dev/disk/by-id/dm-uuid-LVM-RBGwiMghcHZfY95VC5SeHFT20xaKJp1EIOBOK3Ejxq1FTfDKI4HngfgKoihn8G3p", "security.selinux", "system_u:object_r:device_t:s0", 30, 0) = 0
found 'b253:4' claiming '/run/udev/links/\x2fmapper\x2f539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6'
creating link '/dev/mapper/539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6' to '/dev/dm-4'
preserve already existing symlink '/dev/mapper/539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6' to '../dm-4'
[pid 23728] lsetxattr("/dev/mapper/539cfcda--bc30--4e35--845e--888a58229e52-1d84a603--1a4a--461a--af1e--c1541f5f12b6", "security.selinux", "system_u:object_r:device_t:s0", 30, 0) = 0
created db file '/run/udev/data/b253:4' for '/devices/virtual/block/dm-4'

--- Additional comment from Federico Simoncelli on 2014-09-30 05:54:14 EDT ---

It seems that as systemd-udevd is preserving the permissions:

 ...
 preserve permissions /dev/dm-4, 060660, uid=36, gid=107
 ...

it should also preserve the selinux context instead of resetting it with:

 ...
 lsetxattr("/dev/dm-4", "security.selinux", "system_u:object_r:fixed_disk_device_t:s0", 41, 0) = 0
 ...

--- Additional comment from Sandro Bonazzola on 2014-09-30 07:05:20 EDT ---

Not sure it's the same issue but for bug #1142709 I opened bugs on selinux (bug #1146529, bug #1146531) can you see if they're relevant?

--- Additional comment from Federico Simoncelli on 2014-09-30 07:21:28 EDT ---

It seems that the relevant change is:

 22582bb udev: set default rules permissions only at "add" events

http://cgit.freedesktop.org/systemd/systemd/commit/?id=22582bb2cbe85b40de5f561589e0468dac769515

-        if (strcmp(udev_device_get_action(dev), "add") == 0) {
+        if (apply) {
...
                 label_fix(devnode, true, false);
         }

--- Additional comment from Federico Simoncelli on 2014-09-30 09:51:35 EDT ---



--- Additional comment from Federico Simoncelli on 2014-09-30 09:52:06 EDT ---



--- Additional comment from Federico Simoncelli on 2014-09-30 09:53:08 EDT ---

Attached patches for master and fedora 20 are solving the issue.

--- Additional comment from Federico Simoncelli on 2014-09-30 10:48:53 EDT ---

(In reply to Sandro Bonazzola from comment #2)
> Not sure it's the same issue but for bug #1142709 I opened bugs on selinux
> (bug #1146529, bug #1146531) can you see if they're relevant?

It's not related because in that case you use a fully preallocated disk (at least from what I saw from the vdsm.log attached).

Anyway only who's familiar with bug 1142709 can tell if there are other unknown implications.

--- Additional comment from Milos Malik on 2014-10-01 05:44:10 EDT ---

Which version of selinux-policy packages do you have on your system ?

I don't know anything about dmsetup, but selinux-policy-3.12.1-153.el7_0.11 says:

# matchpathcon `which dmsetup`
/usr/sbin/dmsetup	system_u:object_r:lvm_exec_t:s0
# sesearch -s lvm_t -t device_t -T
Found 1 semantic te rules:
   type_transition lvm_t device_t : blk_file fixed_disk_device_t; 

#

--- Additional comment from Kay Sievers on 2014-10-01 05:58:35 EDT ---

Looks like the rules need to be changed to apply MODE= and GROUP= only
at "change" events, then the additional conditional is not needed:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=22582bb2cbe85b40de5f561589e0468dac769515

--- Additional comment from Federico Simoncelli on 2014-10-01 06:57:53 EDT ---

(In reply to Kay Sievers from comment #9)
> Looks like the rules need to be changed to apply MODE= and GROUP= only
> at "change" events, then the additional conditional is not needed:
>  
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=22582bb2cbe85b40de5f561589e0468dac769515

Yes this is something mentioned in comment 3.

In my patches I didn't know if it was possible to skip both permissions change and selinux relabel so I limited it to selinux.

Also because there weren't many information in:

 9a8ae49 udev: always set selinux label at "add" events
 22582bb udev: set default rules permissions only at "add" events

if they were just refactoring then the apply rule should have been just:

 apply = streq(udev_device_get_action(dev), "add");

(IIUC this is what is also suggested in comment 9).

--- Additional comment from Lukáš Nykrýn on 2014-10-01 08:48:09 EDT ---

Set of koji builds:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7740296 http://koji.fedoraproject.org/koji/taskinfo?taskID=7740304 http://koji.fedoraproject.org/koji/taskinfo?taskID=7740309

--- Additional comment from Lukáš Nykrýn on 2014-10-01 08:48:57 EDT ---

But please note that this solution is short term workaround and we should find a better solution.

--- Additional comment from Kay Sievers on 2014-10-01 09:03:48 EDT ---

(In reply to Federico Simoncelli from comment #10)

> if they were just refactoring then the apply rule should have been just:
> 
>  apply = streq(udev_device_get_action(dev), "add");

No, the intendend behavior is that if rules explicitely set something,
also during "change" it should be fully applied.

--- Additional comment from Kay Sievers on 2014-10-01 10:31:09 EDT ---

These patches are not acceptable for Fedora.

I will remove them before the next release. This needs to be solved properly
and not by dirty hacks adding condition and complex implicit rules to udev
code.

Udev is not supposed to be patched like that and we do not add such special
handling.

The disconnect of libvirt mangling device node permissions and triggering
udev rules to do the same is not and will not supported by udev.

Please apply, if possible, your rules on "add" only, so udev will not
reset any metadata on "change" events. Or have libvirt or whatever tool
needs it, write-out the temporary udev rules which also set the selinux
label along with the other properties.

--- Additional comment from Federico Simoncelli on 2014-10-01 10:53:22 EDT ---

(In reply to Kay Sievers from comment #14)
> Please apply, if possible, your rules on "add" only, so udev will not
> reset any metadata on "change" events. Or have libvirt or whatever tool
> needs it, write-out the temporary udev rules which also set the selinux
> label along with the other properties.

Thanks, so it seems that we could solve this by simply updating 12-vdsm-lvm.rules with:

-ACTION!="add", GOTO="lvm_end"
+ACTION!="add|change", GOTO="lvm_end"

I briefly checked it and it seems to work, Nir can you verify it as well? (With a real VM running possibly) Thanks.
At the moment I can't think of any harmful side-effect.

--- Additional comment from Nir Soffer on 2014-10-01 11:24:26 EDT ---

Kay, our rules are basically:

ACTION=="add|change", ENV{DM_VG_NAME}=="...", OWNER:="vdsm", GROUP:="qemu"

Can you explain why modifying the owner and group change the selinux label, and where it is documented that changing these will change the selinux label?

This used to work on RHEL 6.5 for years - why it stopped working now?

--- Additional comment from Nir Soffer on 2014-10-01 11:26:32 EDT ---

(In reply to Federico Simoncelli from comment #15)
> (In reply to Kay Sievers from comment #14)
> > Please apply, if possible, your rules on "add" only, so udev will not
> > reset any metadata on "change" events. Or have libvirt or whatever tool
> > needs it, write-out the temporary udev rules which also set the selinux
> > label along with the other properties.
> 
> Thanks, so it seems that we could solve this by simply updating
> 12-vdsm-lvm.rules with:
> 
> -ACTION!="add", GOTO="lvm_end"
> +ACTION!="add|change", GOTO="lvm_end"
> 
> I briefly checked it and it seems to work, Nir can you verify it as well?
> (With a real VM running possibly) Thanks.
> At the moment I can't think of any harmful side-effect.

We need to understand first, why rules are using "add|change" - maybe it was a hack to avoid a some problem in older rhel?

--- Additional comment from Kay Sievers on 2014-10-01 11:32:51 EDT ---

Device nodes are "owned" by udev if udev is instructed to apply any changes to
them, that includes the selinux label or any other of the metadata.

The split of mangling of permissions/metadata of device nodes between
different tools is not acceptable and not long-term maintainable. Clear
ownership rules are needed, there can only be one tool that manages
them.

The option here is to not tell udev to manage the permissions, meaning
no rules that set them, or tell udev all the needed data in runtime rules.

We must not split them or delegate parts of the permission set to multiple
tools at the same time.

--- Additional comment from Kay Sievers on 2014-10-01 11:57:22 EDT ---

(In reply to Nir Soffer from comment #17)
> (In reply to Federico Simoncelli from comment #15)

> > I briefly checked it and it seems to work, Nir can you verify it as well?
> > (With a real VM running possibly) Thanks.
> > At the moment I can't think of any harmful side-effect.
> 
> We need to understand first, why rules are using "add|change" - maybe it was
> a hack to avoid a some problem in older rhel?

It could be that at the time the "add" is generated, that the device is not
fully set up, and the rules do match at all, hence the "change" is needed.

But as mentioned above, we either manage the permissions by udev or by
libvirt and not by both at the same time. That means that the udev rule
should be deleted and libvirt should do the chown/chmod along with the
selinux label mangling, or libvirt should write out temporary rules that
allow udev to also apply the proper selinux label.

--- Additional comment from Kay Sievers on 2014-10-01 14:26:41 EDT ---

I've reverted the patch in the Fedora package now.

Please find another solution which does not split up permission maintenance between udev and other tools.

Only one of them can own the device node, the current udev logic does and
will not support any special logic or shared permission management.

--- Additional comment from Nir Soffer on 2014-10-02 02:58:57 EDT ---

(In reply to Kay Sievers from comment #20)
> I've reverted the patch in the Fedora package now.
What is "the patch"?

Do you mean that you reverted the fix provided by the builds in comment 11?
If true, then this bug is not MODIFIED any more.

--- Additional comment from Federico Simoncelli on 2014-10-02 04:23:17 EDT ---

(In reply to Kay Sievers from comment #19)
> (In reply to Nir Soffer from comment #17)
> > (In reply to Federico Simoncelli from comment #15)
> 
> > > I briefly checked it and it seems to work, Nir can you verify it as well?
> > > (With a real VM running possibly) Thanks.
> > > At the moment I can't think of any harmful side-effect.
> > 
> > We need to understand first, why rules are using "add|change" - maybe it was
> > a hack to avoid a some problem in older rhel?
> 
> It could be that at the time the "add" is generated, that the device is not
> fully set up, and the rules do match at all, hence the "change" is needed.
> 
> But as mentioned above, we either manage the permissions by udev or by
> libvirt and not by both at the same time.

Agreed, we'll try not to use the udev permissions if possible because there are some assumptions that are not clear.

For example by default the dm device has these permissions:

# ls -l /dev/dm-4 
brw-rw----. 1 root disk 253, 4 Oct  2 07:54 /dev/dm-4

but as soon as we add the rule:

ENV{DM_LV_NAME}=="?*", OWNER:="vdsm"

it becomes:

# ls -l /dev/dm-4 
brw-------. 1 vdsm root 253, 4 Oct  2 07:56 /dev/dm-4

Why? Who asked to change the group?

I am sure the same happens with OWNER and MODE since the apply logic is:

 apply = streq(udev_device_get_action(dev), "add") || event->owner_set || event->group_set || event->mode_set;

And on master even if you specify:

ENV{DM_LV_NAME}=="?*", SECLABEL{selinux}:="system_u:object_r:svirt_image_t:s0"

the label is not applied, unless you specify also one of OWNER|GROUP|MODE (for the same apply logic above).

Why? How should I guess that that's the case?


(In reply to Kay Sievers from comment #14)
> Udev is not supposed to be patched like that and we do not add such special
> handling.

Actually the same approach was already used for permissions, in fact the old:

 streq(udev_device_get_action(dev), "add")

came from:

commit 48a849ee17fb25e0001bfcc0f28a4aa633d016a1
Author: Kay Sievers <kay@vrfy.org>
Date:   Fri Jan 4 16:15:46 2013 +0100

    udev: set device node permissions only at "add" events

because of bug 903716

It seems that the same logic was not considered for the security context.

If a rule specifies an OWNER why udev should change also the GROUP and the SECLABEL?

All these permissions/labels should be independent and not set to any magic default if just one of them is defined.

--- Additional comment from Nir Soffer on 2014-10-02 06:20:23 EDT ---

This looks like a reply of bug 903716.

Kay, you did not answer my question about documentation - is this the old, new and the change in behavior documented somewhere?

--- Additional comment from Kay Sievers on 2014-10-03 06:04:21 EDT ---

There is no explicit documentation. It is just the simple rule: udev
manages all or none of the permissions at "change" events.

Means, either udev manages the permissions or something else, never
multiple tools at the same time

--- Additional comment from Nir Soffer on 2014-10-06 18:17:11 EDT ---

(In reply to Federico Simoncelli from comment #22)
> (In reply to Kay Sievers from comment #19)
> > (In reply to Nir Soffer from comment #17)
> > > (In reply to Federico Simoncelli from comment #15)
>
> And on master even if you specify:
> 
> ENV{DM_LV_NAME}=="?*",
> SECLABEL{selinux}:="system_u:object_r:svirt_image_t:s0"
> 
> the label is not applied, unless you specify also one of OWNER|GROUP|MODE
> (for the same apply logic above).
> 
> Why? How should I guess that that's the case?

Looks like another bug, open another bug for this?

--- Additional comment from Nir Soffer on 2014-10-06 18:22:03 EDT ---

(In reply to Kay Sievers from comment #24)
> There is no explicit documentation. It is just the simple rule: udev
> manages all or none of the permissions at "change" events.
> 
> Means, either udev manages the permissions or something else, never
> multiple tools at the same time

Kay, just to make it clear - would this rule apply any user/group/mode/seclabel?

ACTION=="change", ENV{DM_LV_NAME}=="foo", RUN+="my-program"

According to your reply, this should not cause change in
the the device user, group, mode or selinux label.

--- Additional comment from Nir Soffer on 2014-10-06 18:52:51 EDT ---

Related to bug 1127460 and bug 1149883.

--- Additional comment from Peter Rajnoha on 2014-11-24 07:34:13 EST ---

(In reply to Kay Sievers from comment #19)
> (In reply to Nir Soffer from comment #17)
> > (In reply to Federico Simoncelli from comment #15)
> But as mentioned above, we either manage the permissions by udev or by
> libvirt and not by both at the same time.

I don't understand this. It's udev who manages /dev content, isn't it? And just like we can't create the nodes outside udev and just like we have OWNER/GROUP rules to override defaults for perms, we should have a rule for the selinux context to override defaults if needed.

So what's the problem here? Is it just about backporting the upstream patch? Or is there anything else?

--- Additional comment from Jan Synacek on 2015-01-06 03:59:54 EST ---

The solution was reverted, I'm putting this bugzilla back to assigned.

--- Additional comment from Kay Sievers on 2015-01-08 05:24:03 EST ---

(In reply to Nir Soffer from comment #26)
> Kay, just to make it clear - would this rule apply any
> user/group/mode/seclabel?
> 
> ACTION=="change", ENV{DM_LV_NAME}=="foo", RUN+="my-program"

"add" events will always reset everything. Any use of OWNER, GROUP, MODE will reset everything to the defaults or current values specified by rules.

RUN in a "change" event will not change anything if OWNER, GROUP, MODE are not applied by any rule.

--- Additional comment from Lennart Poettering on 2015-02-04 15:34:59 EST ---

REassigning to lvm, as this appears to be a bug in lvm's usage of udev, but not in udev.

Comment 2 Nir Soffer 2015-02-05 14:05:34 UTC
This used to work in rhel 6. Undocumented behavior change in udev in rhel7 (and fedora 19) broke this.

Comment 5 Zdenek Kabelac 2015-06-11 11:05:25 UTC
I'm not sure why is this bug created agains lvm2 -  since lvm2 cannot not fix it.

Should be likely passed to udev ?

Comment 6 Nir Soffer 2015-06-11 12:57:37 UTC
(In reply to Zdenek Kabelac from comment #5)
> I'm not sure why is this bug created agains lvm2 -  since lvm2 cannot not
> fix it.
> 
> Should be likely passed to udev ?

Sure, this looks like udev bug to me, but I guess it should use the same component of the bug it was cloned from.

Comment 7 Peter Rajnoha 2015-07-21 14:40:05 UTC
Moving this to libvirt to make use of the new SECLABEL=value variable (see man ude) that can be set in udev rules and then interpreted by udev to set the exact selinux label needed.

If the "value" is configure outside, it needs to be imported to udev with PROGRAM=... rule first.

Comment 8 Martin Kletzander 2015-07-22 14:57:31 UTC
Having a binary that is able to get the current label that the device should have would not be such a big deal.  The problem is that libvirtd (or virtlockd) would need to keep track of what the current label should be.  And I'm afraid this might be blocked by Bug 547546.  But then, the binary could just contact socket-activated virtlockd (for example) and export that label that needs to be set.  I'm just wondering how come the seclabel gets changed, but the DAC permissions are kept?

Comment 9 Laine Stump 2015-07-22 15:15:17 UTC
Note that the Fedora BZ this was cloned from (Bug 1147910) has several extra comments added after the cloning (32 and beyond) which are useful reading; in particular Dan's comment about the racy nature of udev's selinux labelling (see Bug 798605 for an example of that raciness in action - and that was in a situation when no new udev rules were added / the rule table wasn't reloaded).

Comment 10 Peter Rajnoha 2015-07-23 06:58:49 UTC
I think the user/group/mode setting itself is racy in udev - the device nodes are created first in devtmpfs in kernel with defaults and then changed a few moments later when the actual event is processed in userspace and then proper rights set based on udev USER/GROUP/MODE udev rule. So we already have a race there even with setting the usual permissions.

Comment 12 Jaroslav Suchanek 2015-11-26 14:34:14 UTC
*** Bug 1265024 has been marked as a duplicate of this bug. ***

Comment 15 Michal Privoznik 2016-11-10 16:41:17 UTC
I think this bug is the same as bug 13542

Comment 16 Michal Privoznik 2016-11-10 16:42:57 UTC
D'oh. Somehow part of my message got lost. What I wanted to say is that I think this is the same as bug 1354251. The fix that I am working on right now would therefore fix this one too.

Comment 17 Michal Privoznik 2017-03-03 14:43:36 UTC
This one is fixed now. I mean, as I explained in bug 1147910#c51 the fix as implemented by libvirt is to run qemu in a namespace with a separate /dev mount managed by libvirt. Therefore, udev no longer can mangle security labels for qemu. Some initial work was done in 3.0.0 release, but since this was a feature that touched the very core of libvirt it wasn't properly working until 3.1.0 release. The list of patches that implement the feature (and fix it) is very long, so unless somebody is really interested, I'm not going to paste it here.

Comment 19 yafu 2017-06-20 08:33:11 UTC
Reproduced with:
libvirt-2.0.0-10.el7_3.9.x86_64
systemd-219-30.el7_3.9.x86_64

Reproduce steps:
1.Add the udev rules in the host os and reboot the host os :
# cat /usr/lib/udev/rules.d/96-test-lvm.rules 
ACTION=="add|change", OWNER:="root", GROUP:="disk"
ENV{DM_UUID}!="LVM-?*", GOTO="lvm_end"
LABEL="lvm_end"

#reboot

2.Start a guest whose os is running on the dm device:
#virsh dumpxml rhel7.3-min
...
<disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/dm-2'/>
      <backingStore/>
      <target dev='vdd' bus='virtio'/>
      <boot order='1'/>
      <alias name='virtio-disk3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</disk>
...

3.Check the selinux context of the dm device:
# ll -Z /dev/dm-2 
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c227,c231 /dev/dm-2

4.Suspend and resume the dm device:
#dmsetup suspend /dev/dm-3
#dmsetup resume /dev/dm-3

5.Check the selinux context of the dm device after step 4:
# ll -Z /dev/dm-2 
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-2

6.The guest os will crashed since I/O error after step 5.


Verified pass with:
libvirt-3.2.0-10.el7.x86_64
systemd-219-41.el7.x86_64

Test steps:
1.Repeat step1-2 in the reproduce steps;

2.Check the selinux context of the dm device both in the host os and qemu process namespaces:
(1)In the host os:
#ll -Z /dev/dm-2 
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-2

(2)In the qemu process namespaces:
#lsns | grep -i qemu
4026532507 mnt        1  5356 qemu   /usr/libexec/qemu-kvm -name guest=rhel7.3-min,debug-threads=on -S ...
# nsenter -t 5356 -m
# ll -Z /dev/dm-2 
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c746,c887 /dev/dm-2

3.Suspend and resume the dm device:
#dmsetup suspend /dev/dm-3
#dmsetup resume /dev/dm-3

4.Check the selinux context of the dm device both in the host os and qemu process namespaces after step 4:
(1)In the host os:
#ll -Z /dev/dm-2 
brw-rw----. root disk system_u:object_r:fixed_disk_device_t:s0 /dev/dm-2

(2)In the qemu process namespaces:
#lsns | grep -i qemu
4026532507 mnt        1  5356 qemu   /usr/libexec/qemu-kvm -name guest=rhel7.3-min,debug-threads=on -S ...
# nsenter -t 5356 -m
# ll -Z /dev/dm-2 
brw-rw----. qemu qemu system_u:object_r:svirt_image_t:s0:c746,c887 /dev/dm-2

5.The guest os still running correctly after step 4;

Comment 20 yafu 2017-06-22 11:33:31 UTC
According to comment 19, move this bug to verified.

Comment 21 errata-xmlrpc 2017-08-01 17:06:41 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846

Comment 22 errata-xmlrpc 2017-08-01 23:48:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846

Comment 23 errata-xmlrpc 2017-08-02 01:25:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846


Note You need to log in before you can comment on or make changes to this bug.