With respect to the libvirt VNC and Monitor sockets, i.e.:
I've noticed the following:
1) Unlike on other files (e.g. in /var/lib/libvirt/images) libvirtd doesn't check for their permissions/owners on the VNC sockets and re-set them if necessary.
This may of course be just what you want, to allow users to manually set different owners/permissions. Just wanted to bring it to your attention in case it's not intended
2) While the .monitor sockets are removed when the respective VM is not running, th .vnc sockets remain in place.
Again,... might be just desired as it is,... so simply close that ticket if that's on purpose.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.
More information and reason for this action is here:
Sent a patch for the permissions issue:
We do want to change those permissions, otherwise qemu might not even be able to start.
WRT to cleaning up the VNC socket... it probably makes sense to do that if vnc_auto_unix_socket is used, but we would need to be careful not to unlink a socket the user manually specifies if for some reason they want it to stay existing. Either way it's not a big issue since it doesn't seem to be causing problems
If you see the thread, I posted some more info. Apparently you can bind to an existing unix socket path, so qemu unlinks the socket first anyways. So changing the permissions ahead of time doesn't do much. My patch was busted anyways :/
There's still some minor issues with VNC sockets outlined in the mail, but the this bug can just be closed
I'm a bit unsure what that means, cause even if qemu unliks first, then the socket still seems to have the wrong permissions, while the other sockets don't.
So I can't quite believe this is fixed.
What is 'wrong' permissions exactly? Is this failing for you somehow?
Well as I've said in the original report,... it's strange that you "correct" the (potentially too open) permissions for the other sockets but not for the mentioned ones.
So I think these permissions should be re-set as well.
(In reply to Christoph Anton Mitterer from comment #6)
> Well as I've said in the original report,... it's strange that you "correct"
> the (potentially too open) permissions for the other sockets but not for the
> mentioned ones.
> So I think these permissions should be re-set as well.
Can you please give explicit details about what permissions you expect, and instead what permissions you are seeing? Especially compared to other sockets.
Since AFAICT any unix socket passed to qemu should end up with roughly the same permissions after the VM has started: 775 with uid:gid matching the qemu process.
(Even though libvirt attempts to change socket permissions for other character devices, that's basically a bug since with qemu it's completely redundant)
As mentioned in comment #7, there's really not much more we can do here, so closing