[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