On Tue, Aug 30, 2011 at 10:51:33AM -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.
The app armour code here was just copied from the similarly name SetImageFDLabel, which resolves the FD into a file path using /proc/self/fd/$FDNUM. This actually never worked for TCP sockets with apparmour, so I don't believe I'm making anything worse. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|