mirror of https://gitee.com/openkylin/libvirt.git
0c0e0d0263
The current security driver architecture has the following
split of logic
* domainGenSecurityLabel
Allocate the unique label for the domain about to be started
* domainGetSecurityLabel
Retrieve the current live security label for a process
* domainSetSecurityLabel
Apply the previously allocated label to the current process
Setup all disk image / device labelling
* domainRestoreSecurityLabel
Restore the original disk image / device labelling.
Release the unique label for the domain
The 'domainSetSecurityLabel' method is special because it runs
in the context of the child process between the fork + exec.
This is require in order to set the process label. It is not
required in order to label disks/devices though. Having the
disk labelling code run in the child process limits what it
can do.
In particularly libvirtd would like to remember the current
disk image label, and only change shared image labels for the
first VM to start. This requires use & update of global state
in the libvirtd daemon, and thus cannot run in the child
process context.
The solution is to split domainSetSecurityLabel into two parts,
one applies process label, and the other handles disk image
labelling. At the same time domainRestoreSecurityLabel is
similarly split, just so that it matches the style. Thus the
previous 4 methods are replaced by the following 6 new methods
* domainGenSecurityLabel
Allocate the unique label for the domain about to be started
No actual change here.
* domainReleaseSecurityLabel
Release the unique label for the domain
* domainGetSecurityProcessLabel
Retrieve the current live security label for a process
Merely renamed for clarity.
* domainSetSecurityProcessLabel
Apply the previously allocated label to the current process
* domainRestoreSecurityAllLabel
Restore the original disk image / device labelling.
* domainSetSecurityAllLabel
Setup all disk image / device labelling
The SELinux and AppArmour drivers are then updated to comply with
this new spec. Notice that the AppArmour driver was actually a
little different. It was creating its profile for the disk image
and device labels in the 'domainGenSecurityLabel' method, where as
the SELinux driver did it in 'domainSetSecurityLabel'. With the
new method split, we can have consistency, with both drivers doing
that in the domainSetSecurityAllLabel method.
NB, the AppArmour changes here haven't been compiled so may not
build.
|
||
|---|---|---|
| .gnulib@146d914507 | ||
| build-aux | ||
| daemon | ||
| docs | ||
| examples | ||
| include | ||
| m4 | ||
| po | ||
| proxy | ||
| python | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| .gitmodules | ||
| .hgignore | ||
| .x-sc_avoid_ctype_macros | ||
| .x-sc_avoid_if_before_free | ||
| .x-sc_avoid_write | ||
| .x-sc_m4_quote_check | ||
| .x-sc_prohibit_HAVE_MBRTOWC | ||
| .x-sc_prohibit_VIR_ERR_NO_MEMORY | ||
| .x-sc_prohibit_asprintf | ||
| .x-sc_prohibit_gethostby | ||
| .x-sc_prohibit_gethostname | ||
| .x-sc_prohibit_have_config_h | ||
| .x-sc_prohibit_nonreentrant | ||
| .x-sc_prohibit_strcmp | ||
| .x-sc_prohibit_strcmp_and_strncmp | ||
| .x-sc_prohibit_strncpy | ||
| .x-sc_require_config_h | ||
| .x-sc_require_config_h_first | ||
| .x-sc_trailing_blank | ||
| AUTHORS | ||
| COPYING.LIB | ||
| ChangeLog-old | ||
| HACKING | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| README | ||
| README-hacking | ||
| TODO | ||
| acinclude.m4 | ||
| autobuild.sh | ||
| autogen.sh | ||
| bootstrap | ||
| cfg.mk | ||
| configure.in | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| mingw32-libvirt.spec.in | ||
README
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>