Bug 1151762 - vnc sockets aren't removed when unused and permissions aren't re-set
Summary: vnc sockets aren't removed when unused and permissions aren't re-set
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 22
Hardware: All
OS: All
unspecified
low
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-11 15:48 UTC by Christoph Anton Mitterer
Modified: 2015-09-20 19:40 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-20 19:40:23 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Christoph Anton Mitterer 2014-10-11 15:48:32 UTC
Hi.

With respect to the libvirt VNC and Monitor sockets, i.e.:
/var/lib/libvirt/qemu/someVM.monitor
/var/lib/libvirt/qemu/someVM.vnc

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.



Cheers,
Chris.

Comment 1 Jaroslav Reznik 2015-03-03 16:21:29 UTC
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:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 2 Cole Robinson 2015-04-29 00:16:03 UTC
Sent a patch for the permissions issue:

https://www.redhat.com/archives/libvir-list/2015-April/msg01485.html

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

Comment 3 Cole Robinson 2015-04-29 17:46:15 UTC
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

Comment 4 Christoph Anton Mitterer 2015-04-29 19:03:14 UTC
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.

Comment 5 Cole Robinson 2015-04-29 19:45:36 UTC
What is 'wrong' permissions exactly? Is this failing for you somehow?

Comment 6 Christoph Anton Mitterer 2015-05-11 18:04:35 UTC
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.

Comment 7 Cole Robinson 2015-05-19 00:35:36 UTC
(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)

Comment 8 Cole Robinson 2015-09-20 19:40:23 UTC
As mentioned in comment #7, there's really not much more we can do here, so closing


Note You need to log in before you can comment on or make changes to this bug.