I would say here that we're going to "convert" the rememberOwner
configuration knob into a security driver "lock" knob that will
effectively enable or disable the usage of metadata locking for the object.
When metadata locking is enabled that means the security commit
processing will be run in a fork similar to how namespaces use fork()'s
for processing. This is done to ensure libvirt can properly and
synchronously modify the metadata to store the original owner data.
Since fork()'s (e.g. virFork) have been seen as a performance bottleneck
being able to disable them allows the admin to choose whether the
performance 'hit' is worth the extra 'security' of being able to
remember the original owner of a lock.
[you could move some of the above back a commit too, but I think it may
get lost there... wordsmithing anything I didn't quite explain right is
fine too. the important part being that we're converting bool names and
that it's a performance tradeoff]
On 11/14/18 7:44 AM, Michal Privoznik wrote:
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_security.c | 73 ++++++++++++++++++++++++---------
src/security/security_dac.c | 56 ++++++++++++++++---------
src/security/security_driver.h | 3 +-
src/security/security_manager.c | 9 +++-
src/security/security_manager.h | 3 +-
src/security/security_selinux.c | 54 ++++++++++++++++--------
src/security/security_stack.c | 5 ++-
7 files changed, 140 insertions(+), 63 deletions(-)
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John