]> xenbits.xensource.com Git - people/liuw/libxenctrl-split/libvirt.git/commit
security: add new virSecurityManagerSetChildProcessLabel API
authorLaine Stump <laine@laine.org>
Fri, 1 Feb 2013 20:02:03 +0000 (15:02 -0500)
committerLaine Stump <laine@laine.org>
Wed, 13 Feb 2013 21:11:16 +0000 (16:11 -0500)
commit7bf1aa0b9b60c3e83c2a89e11010350551218593
tree26abf2d28137a7135bbf11d219d91c76ba438f32
parent6c3f3d0d89b4db87c3dcc2b41903ca30c1595965
security: add new virSecurityManagerSetChildProcessLabel API

The existing virSecurityManagerSetProcessLabel() API is designed so
that it must be called after forking the child process, but before
exec'ing the child. Due to the way the virCommand API works, that
means it needs to be put in a "hook" function that virCommand is told
to call out to at that time.

Setting the child process label is a basic enough need when executing
any process that virCommand should have a method of doing that. But
virCommand must be told what label to set, and only the security
driver knows the answer to that question.

The new virSecurityManagerSet*Child*ProcessLabel() API is the way to
transfer the knowledge about what label to set from the security
driver to the virCommand object. It is given a virCommandPtr, and each
security driver calls the appropriate virCommand* API to tell
virCommand what to do between fork and exec.

1) in the case of the DAC security driver, it calls
virCommandSetUID/GID() to set a uid and gid that must be set for the
child process.

2) for the SELinux security driver, it calls
virCommandSetSELinuxLabel() to save a copy of the char* that will be
sent to setexeccon_raw() *after forking the child process*.

3) for the AppArmor security drivers, it calls
virCommandSetAppArmorProfile() to save a copy of the char* that will
be sent to aa_change_profile() *after forking the child process*.

With this new API in place, we will be able to remove
virSecurityManagerSetProcessLabel() from any virCommand pre-exec
hooks.

(Unfortunately, the LXC driver uses clone() rather than virCommand, so
it can't take advantage of this new security driver API, meaning that
we need to keep around the older virSecurityManagerSetProcessLabel(),
at least for now.)
src/libvirt_private.syms
src/security/security_apparmor.c
src/security/security_dac.c
src/security/security_driver.h
src/security/security_manager.c
src/security/security_manager.h
src/security/security_nop.c
src/security/security_selinux.c
src/security/security_stack.c