On 03/24/2010 07:29 AM, Avi Kivity wrote:
On 03/24/2010 02:23 PM, Anthony Liguori wrote:
On 03/24/2010 05:42 AM, Avi Kivity wrote:
The filtering access part of this daemon is also not mapping well onto
libvirt's access model, because we don't soley filter based on UID in
libvirtd. We have it configurable based on UID, policykit, SASL,
TLS/x509
already, and intend adding role based access control to further filter
things, integrating with the existing apparmour/selinux security
models.
A qemud that filters based on UID only, gives users a side-channel
to get
around libvirt's access control.
That's true. Any time you write a multiplexer these issues crop
up. Much better to stay in single process land where everything is
already taken care of.
What does a multiplexer give you that making individual qemu
instances discoverable doesn't give you? The later doesn't suffer
from these problems.
You don't get a directory filled with a zillion socket files pointing
at dead guests. Agree that's a poor return on investment.
Deleting it on atexit combined with flushing the whole directory at
startup is a pretty reasonable solution to this (which is ultimately how
the entirety of /var/run behaves).
If you're really paranoid, you can fork() a helper with a shared pipe to
implement unlink on close.
Regards,
Anthony Liguori
Maybe we want a O_UNLINK_ON_CLOSE for unix domain sockets - but no,
that's not implementable.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list