Daniel P. Berrangé <berra...@redhat.com> writes: > On Fri, Apr 20, 2018 at 04:50:38PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> > On Fri, Apr 20, 2018 at 03:34:26PM +0200, Markus Armbruster wrote: >> >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> >> >> > Yeah this is a mess - I wish we had never allowed users to pass a config >> >> > file, and had used /dev/null all the time. Unfortunately changing either >> >> > of these aspects would cause backcompat problems for existing >> >> > deployments >> >> > now :-( So we just have to accept that the global config file is always >> >> > in present, but none the less libvirt should try to specify things as >> >> > fully as possible. >> >> >> >> I'm afraid you get backward compatibility problems no matter what. >> >> Whenever you extend libvirt to pass configuration C "via normal per-disk >> >> setup for blockdev", it breaks user config files containing C, doesn't >> >> it? >> > >> > That's not actually a problem here. We are only passing things to QEMU >> > that the user already provided us in the XML file. If we gain support >> > for passing a new item via the blockdev schema, then we'd only be >> > passing that to QEMU if the user actually provided that item in the >> > XML too. We're not likely to pass a new config field without the >> > user having asked us to first. >> >> What made me guess otherwise: "to properly protect against compromised >> QEMU, ideally every QEMU would use a completely separate RBD >> user+password, so that compromised QEMU can't then access RBD disks >> belonging to a different user" led me to assume libvirt would do this >> automatically. > > No, a mgmt app like OpenStack would have to take care of that, as it > needs the ability to manage the RBD user accounts & volume ACLs, to > match the VMs you're creating. > > I just meant that even if you have auth info in the global RBD file, > we shouldn't assume that auth info is desirable to use with QEMU. The > global auth config file may be an administrative account, while each > QEMU has its own restricted account.
I understand now, thanks.
