[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Remove bogus virSecurityManagerSetProcessFDLabel method



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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]