On Tue, 2011-08-30 at 10:51 -0600, Eric Blake wrote:
> 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.
>
ACK. Like Daniel said in another response, this was just copied over
code and not something that is used by the AppArmor driver in any
meaningful way.
--
Jamie Strandboge | http://www.canonical.com
Attachment:
signature.asc
Description: This is a digitally signed message part
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list