Hi Jamie,
I realized I went about this the wrong way. Like you said, it wouldn't
be correct to add these capabilities to all VMs, or I guess I would also
feel uneasy about doing this unless there's good reason. Ultimately,
I'm just trying to solve the problem of getting DENIED for my file
operations and I had thought that the patch from bug #1285995 is already
applied.
However, when I took a closer look, it seems that the full functionality
of the original patch from the proposed patch in that bug was not
applied. Here is the original patch at least attached on launchpad:
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index b9282b4..c02bf99 100644
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -928,6 +928,16 @@ get_files(vahControl * ctl)
goto cleanup;
}
+ for (i = 0; i < ctl->def->nfss; i++)
+ if (ctl->def->fss[i] &&
+ ctl->def->fss[i]->type == VIR_DOMAIN_FS_TYPE_MOUNT &&
+ (ctl->def->fss[i]->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_PATH ||
+ ctl->def->fss[i]->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_DEFAULT)
&&
+ ctl->def->fss[i]->src){
+ virBufferAsprintf(&buf, " \"%s/\" rwk,\n",
ctl->def->fss[i]->src);
+ virBufferAsprintf(&buf, " \"%s/**\" lrwmk,\n",
ctl->def->fss[i]->src);
+ }
+
for (i = 0; i < ctl->def->nserials; i++)
if (ctl->def->serials[i] &&
(ctl->def->serials[i]->source.type == VIR_DOMAIN_CHR_TYPE_PTY ||
However, here is an excerpt of what eventually made it upstream was:
diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
index e7f1359..2396715 100644 (file)
--- a/src/security/virt-aa-helper.c
+++ b/src/security/virt-aa-helper.c
@@ -816,10 +813,14 @@ vah_add_file(virBufferPtr buf, const char *path, const
char *perms)
goto cleanup;
}
- virBufferAsprintf(buf, " \"%s\" %s,\n", tmp, perms);
+ virBufferAsprintf(buf, " \"%s%s\" %s,\n", tmp, recursive ? "/**" : "",
perms);
if (readonly) {
virBufferAddLit(buf, " # don't audit writes to readonly files\n");
- virBufferAsprintf(buf, " deny \"%s\" w,\n", tmp);
+ virBufferAsprintf(buf, " deny \"%s%s\" w,\n", tmp, recursive ? "/**"
: "");
+ }
+ if (recursive) {
+ /* allow reading (but not creating) the dir */
+ virBufferAsprintf(buf, " \"%s/\" r,\n", tmp);
}
cleanup:
@@ -1077,6 +1084,19 @@ get_files(vahControl * ctl)
} /* switch */
}
+ for (i = 0; i < ctl->def->nfss; i++) {
+ if (ctl->def->fss[i] &&
+ ctl->def->fss[i]->type == VIR_DOMAIN_FS_TYPE_MOUNT &&
+ (ctl->def->fss[i]->fsdriver == VIR_DOMAIN_FS_DRIVER_TYPE_PATH
||
+ ctl->def->fss[i]->fsdriver ==
VIR_DOMAIN_FS_DRIVER_TYPE_DEFAULT) &&
+ ctl->def->fss[i]->src){
+ virDomainFSDefPtr fs = ctl->def->fss[i];
+
+ if (vah_add_path(&buf, fs->src, fs->readonly ? "r" : "rw", true)
!= 0)
+ goto cleanup;
+ }
+ }
+
if (ctl->newfile)
if (vah_add_file(&buf, ctl->newfile, "rw") != 0)
goto cleanup;
I see that in vah_add_path, there is a comment that says /* allow
reading (but not creating) the dir */. Indeed, the resulting apparmor
profile is like so:
/etc/apparmor.d/libvirt/libvirt-865a1f4b-f7ab-428f-aa56-f30631565191.files
"/home/user/share/**" rw,
"/home/user/share/" r,
I'm wondering why locking and linking got removed in what was eventually
applied upstream? I wonder if this is the reason for the problems I'm
experiencing.
As I look further into this. I realize that from within the guest I'm
actually able to append to existing files within my shares as well as
create symbolic links and remove files and directories. However, I
cannot create directories, I cannot create hard links to files, and I
cannot create files. The error I get is the DENIED error in the syslog
that I've posted in the original bug post above. Ultimately, I just
want full read and write access from within the guest.
To answer your question about my current environment. I'm currently
running a guest that can mount 9p filesystems with rw. I'd like these
mounts to have full read and write access (as long as readonly is not
configured for the domain). Currently, I have qemu configured to run as
root on /etc/libvirt/qemu.conf. Even running as root, I still get
DENIED while trying to create files/directories and hard links.
Any thoughts? It sounds like whatever should be patched, it should be
done on virt-aa-helper to set up the profile properly. Honestly, I'm
pretty new to AppArmor (or even SELinux) so I'm not familiar with
configuring capabilities and permissions. Let me know what you think is
the best way. Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1324251
Title:
AppArmor denies guest from create/modify 9pfs files
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1324251/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
