Bug 1151762

Summary:	vnc sockets aren't removed when unused and permissions aren't re-set
Product:	[Fedora] Fedora	Reporter:	Christoph Anton Mitterer <calestyo>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	22	CC:	agedosier, berrange, calestyo, clalancette, crobinso, itamar, jforbes, laine, libvirt-maint, veillard, virt-maint
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-09-20 19:40:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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