[libvirt] [PATCH v2 12/19] security: Wire up virUdevMgr

[Daniel P. Berrange]

On Thu, Nov 03, 2016 at 08:19:02PM +0800, Michal Privoznik wrote:
> Whenever a security driver wants to change label of some path, it
> should let virUdevMgr module know so that it can update its
> internal database too.
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/libvirt_private.syms        |  2 ++
>  src/security/security_dac.c     | 36 ++++++++++++++++++++++++++++---
>  src/security/security_manager.c | 16 ++++++++++++++
>  src/security/security_manager.h |  5 +++++
>  src/security/security_selinux.c | 47 ++++++++++++++++++++++++++++++++++++++---
>  5 files changed, 100 insertions(+), 6 deletions(-)


> @@ -382,6 +408,7 @@ virSecurityDACRestoreFileLabelInternal(virSecurityManagerPtr mgr,
>                                         const char *path)
>  {
>      virSecurityDACDataPtr priv = virSecurityManagerGetPrivateData(mgr);
> +    virUdevMgrPtr udevMgr = virSecurityManagerGetUdevManager(mgr);
>      int rv;
>      uid_t uid = 0;  /* By default return to root:root */
>      gid_t gid = 0;
> @@ -399,6 +426,9 @@ virSecurityDACRestoreFileLabelInternal(virSecurityManagerPtr mgr,
>              return -1;
>          if (rv > 0)
>              return 0;
> +
> +        if (udevMgr)
> +            virUdevMgrRemoveAllLabels(udevMgr, path);
>      }

NB, this code path is never going to be reached for any disks that are marked
shared or readonly, since we've still not got a solution for ref counting of
shared disks. This will cause the JSON file database to grow without bound
until the host is rebooted, which is undesirable and could cause performance
issues for hosts which start/stop alot of guests with shared/readonly disks.

Fixing the shared disks problem will require us to maintain a database of
information about labelling/owership of files and devices, synchronized
across hosts. IMHO it is undesirable for us to end of maintaining the
same information in two separate places, once for udev and once for the
more general case. 

If we address the more general case first, then the majority of this series
is not required, as we would already have a suitable database of information.
We would only need the udev specific helper to query it.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|