[libvirt] [PATCH] Remove bogus virSecurityManagerSetProcessFDLabel method
Eric Blake
eblake at redhat.com
Tue Aug 30 16:51:33 UTC 2011
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 at redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
More information about the libvir-list
mailing list