[libvirt-users] What is the purpose behind the unix_sock_admin_perms in libvirtd.conf?

[Erik Skultety]

On 29/09/16 16:25, mordenkainen wrote:
> I tried to google any documentation on libvirtd.conf format and options and found nothing. Could you give an insight on how it was supposed to configure libvirtd without comprehensive documentation on it?
> 

That depends on what you're trying to achieve if you describe your
intended use case thoroughly we might be able to give you a better
answer. The configuration file does contain plenty of commentaries on
what purpose does each parameter serve, although I can understand your
concern and definitely can imagine having some extensive documentation
for the config with some examples as well as some tutorials for users
starting with libvirt (I have it on my TODO list, though not with the
highest priority).

To answer your question in subject (unix_sock_admin_perms purpose), by
changing the permissions on the admin socket you allow users with enough
privileges to connect to the admin socket and configure the daemon
during runtime. First, dropping the admin socket privileges (root only
by default) is not recommended unless you really know what you're doing
and fully understand all possible outcomes and that is because you're
able to tweak the maximum number of allowed clients connected to the
daemon, force close existing connections, manipulating the amount of
worker threads in the threadpool, etc. In wrong hands, the APIs
designated to accomplish the operations mentioned above can be used to
perform DOS attack on the daemon. Secondly, the libvirtd.conf file can
only be edited by root by default, so it was only natural that the
default choice on the admin unix socket permissions would be root-only.

Before the administration interface was introduced in libvirt, the only
way how to configure libvirtd daemon was via libvirtd.conf, which you've
already come across. Editing the configuration via this file however
only provides users with persistent configuration, therefore we came up
with the administration interface, to be able to alter the runtime
configuration of the daemon (but not all configuration parameters that
can be found in the config file can be modified during runtime at the
moment).

Regards,
Erik