
----- Original Message -----
From: "Gilad Chaplik" <gchaplik@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: engine-devel@ovirt.org, "Michal Skrivanek" <mskrivan@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com>, "Livnat Peer" <lpeer@redhat.com> Sent: Wednesday, November 14, 2012 10:21:11 AM Subject: Re: [Engine-devel] Managing permissions on network
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Livnat Peer" <lpeer@redhat.com> Cc: engine-devel@ovirt.org, "Michal Skrivanek" <mskrivan@redhat.com>, "Andrew Cathrow" <acathrow@redhat.com>, "Gilad Chaplik" <gchaplik@redhat.com>, "Doron Fediuck" <dfediuck@redhat.com> Sent: Tuesday, November 13, 2012 8:19:01 PM Subject: Re: [Engine-devel] Managing permissions on network
On 11/13/2012 07:18 PM, Livnat Peer wrote:
On 13/11/12 15:39, Itamar Heim wrote:
On 11/13/2012 03:37 PM, Livnat Peer wrote:
On 13/11/12 15:19, Itamar Heim wrote:
On 11/13/2012 12:45 PM, Livnat Peer wrote: > Interesting point, I think that if a user has permission to > create a VM > from a specific template we should give him permission to use > the > template networks on this VM implicitly upon the VM creation.
having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types.
Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)).
Anyone has a better idea?
I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user.
Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user.
In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks.
In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM.
I think that's fine. don't let user edit that vm if you don't trust them.
i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)?
I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota.
gilad/doron?
No implicit permissions. IIRC it was never implemented
As the quota is a logical limitation for a resource, the user should first have relevant permissions for the relevant entity, and if needed, he should have consumption right (ActionGroup.CONSUME_QUOTA) to use the resource. So going forward I expect network quota to behave the same; ie- a user should have consumption rights for the relevant network resource on top of security permissions.