On 08/30/2011 10:37 AM, Daniel P. Berrange wrote:
The virSecurityManagerSetProcessFDLabel method was introduced
after a mis-understanding from a conversation about SELinux
socket labelling. The virSecurityManagerSetSocketLabel method
should have been used for all such scenarios.
* src/security/security_apparmor.c, src/security/security_apparmor.c,
src/security/security_driver.h, src/security/security_manager.c,
src/security/security_manager.h, src/security/security_selinux.c,
src/security/security_stack.c: Remove SetProcessFDLabel driver
---
+++ b/src/security/security_apparmor.c
@@ -799,34 +799,6 @@ AppArmorSetImageFDLabel(virSecurityManagerPtr mgr,
return reload_profile(mgr, vm, fd_path, true);
}
-static int
-AppArmorSetProcessFDLabel(virSecurityManagerPtr mgr,
- virDomainObjPtr vm,
- int fd)
-{
- int rc = -1;
- char *proc = NULL;
- char *fd_path = NULL;
-
- const virSecurityLabelDefPtr secdef =&vm->def->seclabel;
This is non-trivial code. While we've already determined that SELinux
doesn't need SetProcessFDLabel, is there any chance that app-armor still
needs this approach? If so, that would argue for keeping the function,
but making it a no-op stub for SELinux, and still calling it in all the
right places for the benefit of app-armor.
I'm not familiar enough with app-armor theory of operation to answer
this question, and without an answer, I can't give ack or nack.
--
Eric Blake eblake@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list