On 02/14/2017 04:40 PM, Daniel P. Berrange wrote:
On Tue, Feb 14, 2017 at 04:33:09PM +0100, Andrea Bolognani wrote:
> When we're building a private /dev for the isolated QEMU
> process, we want to be able to replicate the contents of
> the original /dev as closely as possible, including ACLs.
>
> To ensure that's always possible, make ACL support mandatory
> when the QEMU driver is enabled.
>
> Resolves:
https://bugzilla.redhat.com/show_bug.cgi?id=1421036
> ---
> m4/virt-acl.m4 | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/m4/virt-acl.m4 b/m4/virt-acl.m4
> index f7d1c6d..7a8b8e5 100644
> --- a/m4/virt-acl.m4
> +++ b/m4/virt-acl.m4
> @@ -21,6 +21,10 @@ AC_DEFUN([LIBVIRT_CHECK_ACL], [
>
> AC_CHECK_HEADERS([sys/acl.h])
>
> + if test "x$ac_cv_header_sys_acl_h:x$with_qemu" = "xno:xyes";
then
> + AC_MSG_ERROR([Unable to find <sys/acl.h>, required by qemu driver])
> + fi
I understand the desire to simplify the code by assuming the libacl
APIs always exist, but we shouldn't do it this way. Instead we should
follow our normal practice of creating a src/util/viracl.{c,h} file
which wrap the APIs and providing no-op stubs which just raise an
error when the library is missing at build time.
Unfortunately, it's more complicated than that. What if your distro has
getfacl/setfacl but missing the header files (libacl-devel)? In that
case libvirt is built without ACL support. Now imagine you have a
device, say /dev/kvm with 0777 and ACL entry that denies specific
group/user. If we build without ACL support, and use namespaces we will
in fact allow that group/user to start a domain because we just create a
device with 0777 perms and do not copy ACL entries.
Or vice versa - I explicitly allow user under which I'm running in ACLs
to /dev/kvm while it's perms are 0660. Lacking libacl headers would
render me unable to use namespaces.
Michal