Issue with Privileges

[Rhongomiant]

Hello,

First I have to commend the Proxmox staff for the work to get to 3.1. It is sweet.

I am not sure if this is an issue with privileges or custom roles, I want to give users the ability to browse and add ISOs and Templates. However, unless I assign a role with Datastore.Allocate, all users get when they click on a datastore is the "Summary" tab. Below is the description for the datastore privileges and the PVEDatastoreUser has the Datastore.Audit privilege, but users do not get the "Content" tab for a datastore. However, users can choose an item from the datastore with the PVEDatastoreUser role assigned to them.

Datastore.Allocate: create/remove/modify a datastore, delete volumes
Datastore.AllocateSpace: allocate space on a datastore

Datastore.AllocateTemplate: allocate/upload templates and iso images
Datastore.Audit: view/browse a datastore


I created a custom role with the two privileges in the predefined PVEDatastoreUser role and added the Datastore.AllocateTemplate. When users are assigned my custom role they can do everything they could do when assigned to the PVEDatastoreUser role, but nothing more. Below are the relevant items from the /etc/pve/user.cfg file. Is my path wrong to allow users to access the "Content" tab along with access to download templates and upload ISOs? I do not think this is the case because when I assign the role PVEDatastoreAdmin, users have access to all these options.

groupVEVMAdmins:user1@pve,user2@pve,user3@pve::

roleVEDatastorePowerUseratastore.AllocateTemplate,Datastore.Audit,Datastore.AllocateSpace:

acl:1:/storagePVEVMAdminsVEDatastorePowerUser:


I am seeing a little strangeness when users can access the content tab of a datastore.

1) They can only see backups for VMs in the containers to which they have access, but they can see drive images for all VMs.

2) While users can see drive images for all VMs, they cannot delete them from the Content tab. Maybe this is intended and this makes sense, because this is controlled in the VM config.


I find the path option a bit confusing, so I apologize if I am missing something. It looks like the /access path has the options necessary to modify most of the items in the "Datacenter" section. The exceptions are "Search", "Summary", "Options", "Storage", "Backup", "HA" and "Support". Of these only "Options", "Storage", "Backup" and "HA" really make sense for permission control. Access to "Storage" is controlled by Datastore.Allocate and access to "HA" and "Options" is in the "/cluster" path controlled by Sys.Audit. I do not see the ability to give users access to just the "Backup" tab. Is this intended? Is an option for users to be able to control their own automatic backups planned?

 

[dietmar]

Please can you also post your /tec/pve/storage.cfg (so that I can reproduce it here).

 

[Rhongomiant]

Dietmar,

Thanks for the response.

I have posted what you requested below.

dir: local
path /var/lib/vz
content images,iso,vztmpl,backup,rootdir
maxfiles 365


I have found another issue that makes the above concern irrelevant for what I need. I have found that unless I assign users the PVEDatastoreAdmin role, they cannot delete drives from their VMs and they need to be able to delete them. They have no issues adding drives with PVEDatastoreUser role. Is there a way I can give users the ability to delete drives from their own VMs without the ability to modify the storage volume?

 

[dietmar]

I do not see the ability to give users access to just the "Backup" tab. Is this intended? Is an option for users to be able to control their own automatic backups planned?

There is simply no relation between the GUI structure and permission paths. Required permissions are documented for each API call, and are sometimes quite complex.

 

[dietmar]

I would simply define an extra storage for templates:

dir: mytemplates
path /path/to/mytemplates
content iso,templates

And the assign administrator role for the group:

acl:1:/storage/mytemplatesPVEVMAdmin:Administrator:

Does that work as expected?

 

[dietmar]

Is there a way I can give users the ability to delete drives from their own VMs without the ability to modify the storage volume?

They can do that on the VM hardware page (but not on the storage content page).

 

[Rhongomiant]

They can do that on the VM hardware page (but not on the storage content page).

I would simply define an extra storage for templates:

dir: mytemplates
path /path/to/mytemplates
content iso,templates

And the assign administrator role for the group:

acl:1:/storage/mytemplatesPVEVMAdmin:Administrator:

Does that work as expected?

Dietmar,

It looks like you have responded to the same issue twice. In the first response, my first quote above, you suggest that I should segregate the template and iso directories as their own paths and then give users the PVEDatastoreAdmin indicating that either the Datastore.AllocateTemplate privilege does not work or it will not work with the custom role that I assigned.



In your second response, my second quote above, you state that users should be able to delete drives from the VM hardware tab. Well of course they can when assigned the PVEDatastoreAdmin, but since my post has been about not wanting to assign users that role, I assume you mean users should be able to delete drives from their VMs in the VM hardware tab if they are assigned the PVEDatastoreUser role. My problem report is that what you have just described does not work. If assigned the PVEDatastoreUser role users cannot delete hard drives from the hardware tab for their VMs. Previously I posted the contents of my /tec/pve/storage.cfg file and provided the relevant contents of my /etc/pve/user.cfg file showing that the user is part of a group assigned the PVEDatastoreUser for accessing /storage which I assume means any storage drvice, but I have also specified /storage/local. In some of the examples you have seen this custom role, PVEDatastorePowerUser, which is simply the same as the PVEDatastoreUser with the Datastore.AllocateTemplate privilege. I have tried everything with the PVEDatastoreUser assigned to the group.



It seems that things are not working as expected and I understand that for now that I must implement work around. However, I would like someone to confirm the following.



1) I should be able to assign users the PVEDatastoreUser role or a custom role with the privileges Datastore.Audit, Datastore.AllocateSpace, Datastore.AllocateTemplate and these users should be able to delete drives for their own Vms via the hardware tab for their VMs.



2) That if I assign a role the Datastore.AllocateTemplate privilege and assign that role to users, then those users should be able to add an remove ISOs and OpenVZ templates and maybe VM templates. BTW, I would love to be able to segregate VM templates to it's own permission and perhaps allow users to have their own templates that are not shared with everyone with access to the datastore.



If my statements above are true and this is not working for me am I doing something wrong or is something not working right. If something is not working correctly, do you plan to resolve the issue and can I test the fix?


Thanks,

Chris

 

[Rhongomiant]

Hello,

This is a bump as I have not received a response to my last message. I would really like to know if this is a bug or if I am doing something wrong and if it is a bug I would like to know if a fix will be attempted.




Dietmar, I did not specifically respond to your last question because assigning less than the PVEVMAdmin role for the main storage is useless because users cannot delete hard drives from their own VMs from the hardware tab for the VM.




Below is the message I posted 1 Week Ago @ 12:05 PM.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

They can do that on the VM hardware page (but not on the storage content page).

I would simply define an extra storage for templates:

dir: mytemplates
path /path/to/mytemplates
content iso,templates

And the assign administrator role for the group:

acl:1:/storage/mytemplatesPVEVMAdmin:Administrator:

Does that work as expected?

Dietmar,

It looks like you have responded to the same issue twice. In the first response, my first quote above, you suggest that I should segregate the template and iso directories as their own paths and then give users the PVEDatastoreAdmin indicating that either the Datastore.AllocateTemplate privilege does not work or it will not work with the custom role that I assigned.



In your second response, my second quote above, you state that users should be able to delete drives from the VM hardware tab. Well of course they can when assigned the PVEDatastoreAdmin, but since my post has been about not wanting to assign users that role, I assume you mean users should be able to delete drives from their VMs in the VM hardware tab if they are assigned the PVEDatastoreUser role. My problem report is that what you have just described does not work. If assigned the PVEDatastoreUser role users cannot delete hard drives from the hardware tab for their VMs. Previously I posted the contents of my /tec/pve/storage.cfg file and provided the relevant contents of my /etc/pve/user.cfg file showing that the user is part of a group assigned the PVEDatastoreUser for accessing /storage which I assume means any storage drvice, but I have also specified /storage/local. In some of the examples you have seen this custom role, PVEDatastorePowerUser, which is simply the same as the PVEDatastoreUser with the Datastore.AllocateTemplate privilege. I have tried everything with the PVEDatastoreUser assigned to the group.



It seems that things are not working as expected and I understand that for now that I must implement work around. However, I would like someone to confirm the following.



1) I should be able to assign users the PVEDatastoreUser role or a custom role with the privileges Datastore.Audit, Datastore.AllocateSpace, Datastore.AllocateTemplate and these users should be able to delete drives for their own Vms via the hardware tab for their VMs.



2) That if I assign a role the Datastore.AllocateTemplate privilege and assign that role to users, then those users should be able to add an remove ISOs and OpenVZ templates and maybe VM templates. BTW, I would love to be able to segregate VM templates to it's own permission and perhaps allow users to have their own templates that are not shared with everyone with access to the datastore.



If my statements above are true and this is not working for me am I doing something wrong or is something not working right. If something is not working correctly, do you plan to resolve the issue and can I test the fix?


Thanks,

Chris

 

[dietmar]

This is a bump as I have not received a response to my last message. I would really like to know if this is a bug or if I am doing something wrong and if it is a bug I would like to know if a fix will be attempted.

Looks like a bug. I will take a closer look at that in the next days.

 

[Rhongomiant]

Dietmar,

Thanks for the follow up. Just to recap, the two issues I have are as follows. Let me know if I can help test any changes made to resolve permissions issues like the ones reported here.


1) If users are assigned the PVEDatastoreUser role they cannot delete hard drives for their VMs from the hardware tab for their VM. Therefore, my only option is to assign users the PVEDatastoreAdmin role which means they can access hard drives for other users and manipulate the datastore.


2) If I create a custom role, assign the Datastore.AllocateTemplate privilege to this role and assign this role to users for a particular datastore, users cannot modify ISOs or OpenVZ templates.


I am not sure if the Datastore.AllocateTemplate privilege is also supposed to allow access to custom VM templates. It would be nice to allow people to create shared VM templates that can be deleted only by admins and the user that created them.




Just so I am clear, I should be able to provide more specific access control to specific items if I create a datastore for the specific directories below and assign users higher level roles for these specific datastores. Is my assessment correct?



ISOs
/var/lib/vz/template/iso


OpenVZ Templates
/var/lib/vz/template/cache


Custom Templates
/var/lib/vz/template/custom_templates

 

[dietmar]

1) If users are assigned the PVEDatastoreUser role they cannot delete hard drives for their VMs from the hardware tab for their VM. Therefore, my only option is to assign users the PVEDatastoreAdmin role which means they can access hard drives for other users and manipulate the datastore.

I have a fix for this one - please can you test:

# wget ftp://download.proxmox.com/tmp/qemu-server_3.1-2_amd64.deb
# dpkg -i qemu-server_3.1-2_amd64.deb

2) If I create a custom role, assign the Datastore.AllocateTemplate privilege to this role and assign this role to users for a particular datastore, users cannot modify ISOs or OpenVZ templates.

The only way to get such behavior is to setup an extra storage for templates, and assign users PVEDataStoreAdmin role.

 

[Rhongomiant]

Dietmar,

Thanks for the follow up. My responses are below.

I have a fix for this one - please can you test:

# wget ftp://download.proxmox.com/tmp/qemu-server_3.1-2_amd64.deb
# dpkg -i qemu-server_3.1-2_amd64.deb

This is working for me. Thank you for fixing this issue.

The only way to get such behavior is to setup an extra storage for templates, and assign users PVEDataStoreAdmin role.

I have a multiple part response for your response.

1) It would be helpful if you and your colleagues would be a little more specific when you say things like "setup an extra storage for templates" because all of your users are not as familiar with what is allowed and what is not. I realize that I may be stupid, but at the end of the day for what ever reason it is not clear to me what options I have to "setup an extra storage for templates". Sure I am not opposed to tinkering, but I do not want to cause a catastrophic issue either. Anyway...

1a) Are you saying that I have to create multiple storage volumes and dedicate one or multiple to ISO and Templates if I want to give users less permissions for the primary storage volume? It seems inherently counter intuitive to the way that Proxmox is designed since it does not allow for any user controlled partitioning during the install and it seems to have a fairly extensive, but perhaps a little less than 100% complete, permissions system.

1b) I assumed that what I described above was not what you were stating and assumed that I needed to create directory datastores that were more specific like /var/lib/vz/template/iso/ and /var/lib/vz/template/ or /var/lib/vz/template/, but that just created empty cache and ISO directories in those directories which did not make sense. Therefore, I created multiple datastore directories using /var/lib/vz/ just like the "Local" datastore. The "Local" datastore is set to hold all content and I have another datastore set to the directory /var/lib/vz/ that for which iso and template content is allowed and users have been assigned the PVEDatastoreAdmin role.

Is this setup OK?

Is this the setup that you meant?

If not, can you provide a bit more detail of what you wanted me to do?

This setup has some side effects, cosmetic I think, but you should be aware of them.

1b1) If a user is assigned the PVEDatastoreAdmin role for a datastore, images are displayed in the content tab even through images are not one of the content options set for the datastore.

1b2) The "Local" datastore forces you to have the templates content type. If you remove it, it is added back even if you have it set in another datastore using the same path, /var/lib/vz/.

1b3) When a user is assigned a role that gives them access to the "Storage" tab in the "Datacenter" section, they see all datastores which is fine, but they can click the remove button for any datastore and it asks them if they are sure. It gives a permissions error if the user select yes and the user is not assigned a role with the "Datastore.Allocate" permission. For example this happens with the "Local" datastore to which users are assigned the PVEDatastoreUser role. At the end of the day, this is OK, but if you click on edit they get the permissions error immediately. I think you would want to perform the permissions verification before it asks the user if they are sure they want to delete the datastore.

1b4) With my original setup with only the "Local" datastore was set up for /var/lib/vz/ and the users that were not assigned the PVEDatastoreAdmin role could not see the "Content" tab when they clicked on the "Local" datastore. Now I have another datastore using /var/lib/vz/ and users are assigned the PVEDatastoreAdmin to that datastore and users are assigned the PVEDatastoreUser role to the "Local" datastore. These users can see the "Content" tab on all datastores using /var/lib/vz/. These users are given the option to delete and add templates and ISOs when they select the "Content" tab in the "Local" datastore, but of course they are given a permissions error. They can of course add and remove templates and ISOs when they select the "Content" tab in the datastore for which they are assigned the PVEDatastoreAdmin role. In addition if I assign these users my custom role, PVEDatastorePowerUser, which has been assigned the permissions Datastore.Audit, Datastore.AllocateSpace and Datastore.AllocateTemplate to the "Local" datastore, these users can add templates and ISOs when they select the "Content" tab in the "Local" datastore, but the can not delete templates and ISOs. I think that the "Content" tab should only be shown when a user selects a datastore if the user is assigned a role that allows then to add or add and delete items in the datastore using the content tab.


2) In my first response to your message about giving users access to templates and ISOs without allowing them to delete datastores that contain images, backups, etc., I addressed your solution. In this section I will address the fact that the work around you suggest should not be needed in one scenario. Based on my finding that is listed in 1b4 above it seems that the Datastore.AllocateTemplate permission does work, but is not implemented incorrectly as it does not generate what ever is necessary to enable access to the "Content" tab when a datastore is selected by users assigned a role that includes the Datastore.AllocateTemplate permission, but not the Datastore.Allocate permission. The way I discovered that it works, described in 1b4 above, is a pretty convoluted way to enable the use of this permission making it fairly useless.

2a) I think that the solution would be to fix this so that if a role includes the Datastore.AllocateTemplate permission, and if needed the Datastore.AllocateSpace permission and/or the Datastore.Audit permission, and a user is assigned this role for a datastore allowed to access template and/or ISO content, the user should be able add templates and/or ISOs from the "Content" tab of the datastore.

2b) I am not sure what the solution is for removing templates and ISOs. Perhaps there should be an admin level remove templates permission that allows a user to delete any template and/or ISO. However, I would also like to see something like how backups work for templates and ISOs. I understand that the backup system is VM specific so if a user is assigned a role that includes the VM.Backup permission, the user can create and restore backups and with the correct role delete backups for that VM. Perhaps a pool could be a holder of templates and ISO just like it is for VMs without having to assign a datastore to the pool. This marker would determine ownership of the templates and ISOs in the pool and users assigned the correct permissions for the datastore on which the templates and ISOs reside and the pool then they can delete the templates and ISOs in the pool.


While some of the items I listed above are functional issues, most are reports about interface inconsistency issues related to this thread. The two items below are also interface inconsistency issues.

It would be nice if we could create a template from a VM that does not delete the existing VM.

Currently moving VMs between a pool is a pain. If a VM is assigned to one pool and you try to assign it to another pool it gives an error that the VM is already assigned to a pool. You have to remove it from the existing pool and then add it to another pool. IMHO, a user with the permissions to remove the VM from the source pool and add the VM to the destination pool should be presented with a warning that the VM is assigned to pool X and verify that the user wants to move it to pool Y. A real world example is if I assign a user multiple pools, he is not able to move VMs between pools unless I give him enough permissions to access all VMs as when he removes a VM from one pool he looses access to the VM and can't add it to a different pool.

As for pool access it would be nice if a user could be given a permission to see a pool, but have limited editing abilities for the pool.


Thanks for your help Dietmar,

Chris

 

[Rhongomiant]

Dietmar,

I have run into an issue and before I created a new thread I want to make sure that the issue is not related to the qemu-server_3.1-2_amd64.deb. I have not tested this before, but I created a VM Template and when I try to clone it, I get the following error. My searches turned up one thread that indicated this was due to not using qcow2, but this template is using qcow2. I have tried the clone as my use, an full admin user and root and I get this error weather I choose linked or full clone and regardless if I select a pool.

Full clone feature is not available at /usr/share/perl5/PVE/API2/Qemu.pm line 2201. (500)


Let me know if I should create a new thread for this.


Thanks,

Chris

 

[dietmar]

1b) I assumed that what I described above was not what you were stating and assumed that I needed to create directory datastores that were more specific like /var/lib/vz/template/iso/ and /var/lib/vz/template/ or /var/lib/vz/template/, but that just created empty cache and ISO directories in those directories which did not make sense. Therefore, I created multiple datastore directories using /var/lib/vz/ just like the "Local" datastore. The "Local" datastore is set to hold all content and I have another datastore set to the directory /var/lib/vz/ that for which iso and template content is allowed and users have been assigned the PVEDatastoreAdmin role.

Is this setup OK?

Please use an extra directory for the template storage (do not create an alias for the local storage).

I am sorry, but this post is simply too long to answer - I do not have enough time to track such large threads.