From 441f44f75c0d62a93da6b3cedaf55e44ff401fa7 Mon Sep 17 00:00:00 2001 Message-Id: <441f44f75c0d62a93da6b3cedaf55e44ff401fa7@dist-git> From: Michal Privoznik Date: Thu, 18 Sep 2014 11:45:33 +0200 Subject: [PATCH] nvram: Fix permissions https://bugzilla.redhat.com/show_bug.cgi?id=1026772 I've noticed two problem with the automatically created NVRAM varstore file. The first, even though I run qemu as root:root for some reason I get Permission denied when trying to open the _VARS.fd file. The problem is, the upper directory misses execute permissions, which in combination with us dropping some capabilities result in EPERM. The next thing is, that if I switch SELinux to enforcing mode, I get another EPERM because the vars file is not labeled correctly. It is passed to qemu as disk and hence should be labelled as disk. QEMU may write to it eventually, so this is different to kernel or initrd. Signed-off-by: Michal Privoznik (cherry picked from commit 37d8c75fad297891b80086b125046ed3990eaf59) Signed-off-by: Jiri Denemark --- libvirt.spec.in | 2 +- src/security/security_selinux.c | 5 ++++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 65f0d64..1c9150b 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -2298,8 +2298,11 @@ virSecuritySELinuxSetSecurityAllLabel(virSecurityManagerPtr mgr, mgr) < 0) return -1; + /* This is different than kernel or initrd. The nvram store + * is really a disk, qemu can read and write to it. */ if (def->os.loader && def->os.loader->nvram && - virSecuritySELinuxSetFilecon(def->os.loader->nvram, data->content_context) < 0) + secdef && secdef->imagelabel && + virSecuritySELinuxSetFilecon(def->os.loader->nvram, secdef->imagelabel) < 0) return -1; if (def->os.kernel && -- 2.1.0