Bug 790038

Summary:	RFE: allow specifying storage pool permissions at create time
Product:	[Community] Virtualization Tools	Reporter:	Jonathan Underwood <jonathan.underwood>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	berrange, crobinso, cwei, mzhan, zpeng
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-26 17:20:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jonathan Underwood 2012-02-13 14:31:45 UTC

Description of problem:
If one sets up PolicyKit rules to allow non-root users to manage virtual machines, then when creating a new storage pool (directory based) via virt-manager (Edit->Connection Details->Storage Tab), then the new storage pool directory is created with owner and group still as root, and not the user that virt-manager is running under. As a result, that user can't use the storage pool just created for new VMs.

Version-Release number of selected component (if applicable):
virt-manager-0.8.6-4.el6.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Create the file /etc/polkit-1/localauthority/50-local.d/50-virt.pkla with the following contents to allow non-root users to run virt-manager:

[Allow all users libvirt management permissions but require password]
Identity=*
Action=org.libvirt.unix.manage
ResultAny=auth_self_keep
ResultInactive=auth_self_keep
ResultActive=auth_self_keep

2. Start virt-manager as a non-root user
3. Create a new directory based storage pool in virt manager using some new directory
4. Examine the owner and group of that new directory corresponding to the new storage pool - it's root:root.
  
Additional info:
virsh suffers with a similar problem, but I will file a separate bug report for that.

More info on the use-case for this functionality:
http://stuckinadoloop.wordpress.com/2012/02/13/multi-user-use-of-virt-manager/

Comment 2 Cole Robinson 2012-02-13 15:13:05 UTC

Hmmm, I think virt-manager is correct here, just deferring to libvirt's default, which I think is the user:group the daemon is running as. We shouldn't assume that new pools should be accessible by the user running virt-manager, since they are doing so over an authenticated channel (and we have no way of knowing how you configured policykit, just that you managed to authenticate). It's more important that disk images are as isolated as possible by default, yet still 'just work' with new guests.

That said virt-manager should be able to facilitate your use case by allowing the user to manually specify desired permissions at pool create time.

Comment 3 Jonathan Underwood 2012-02-13 15:24:10 UTC

Yes, agreed. The same issue arises with virsh as well (BZ #790045).

Comment 4 RHEL Program Management 2012-07-10 08:44:19 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 RHEL Program Management 2012-07-11 01:56:19 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 6 Cole Robinson 2020-01-26 17:20:52 UTC

virt-manager 2.2.0 has a tab for editing the raw XML of pool objects (and all other objects). That is our planned solution for editing details like this. Closing as CURRENTRELEASE