On Wed, Jan 30, 2019 at 09:06:30AM +0100, Erik Skultety wrote:
Thanks for ^this bit which helped me understand the bits below. When
I read the
man page yesterday the first question was, okay, how do I figure out whether
the file capabilities bit is set? Well, use xattrs...which didn't return
anything, so I was puzzled what exactly it should look like, but now that you
explained that most binaries actually lack the file capabilities, I see the
issue clearly :).
The commands you want to experiment with are "getcap" and "setcap" eg
# getcap qemu-system-x86_64
# setcap cap_dac_override=+ep qemu-system-x86_64
# getcap qemu-system-x86_64
qemu-system-x86_64 = cap_dac_override+ep
# setcap cap_dac_override= qemu-system-x86_64
# getcap qemu-system-x86_64
qemu-system-x86_64 =
# setcap -r qemu-system-x86_64
# getcap qemu-system-x86_64
#
> +
> ret = 0;
> cleanup:
> return ret;
>
>
> though, we need a #ifdef check for existance of PR_CAP_AMBIENT
>
> > An alternative question I've been playing ever since we exchanged the last
few
> > emails is that can't we wait until the ioctls are compared against
permissions
> > in kernel so that upstream libvirt (and downstream too for that matter)
doesn't
> > have to work around it and stick with that workaround for eternity?
>
> IIUC, the SEV feature has already shipped with distros, so we'd effectively
> be saying that what we already shipped is unusable to libvirt. This doesn't
> feel like a desirable story to me.
It was, but it never worked, it always has been broken in this way. When we
were merging this upstream, we had a terrible shortage of machines and we had
to share, so the first person to provision the machine had already taken care
of the permissions in order to test so that led to this issue having been
overlooked until now. If it ever worked as expected and then we broke it, then
any fix from our side would make sense but otherwise I believe we should fix
this bottom up.
Well technically it would work if libvirt was configured to run as
root:root, but yes, that is not a normal or recommended configuration.
Personally I have a preference for userspace solutions, as those are
pretty straightforward to roll out to people as patches in existing
releases. Deploying kernel updates is a higher bar to cross for an
existing release.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|