----- Original Message ----- > From: "Gilad Chaplik" <[email protected]> > To: "Itamar Heim" <[email protected]> > Cc: [email protected], "Michal Skrivanek" <[email protected]>, "Andrew > Cathrow" <[email protected]>, "Doron > Fediuck" <[email protected]>, "Livnat Peer" <[email protected]> > Sent: Wednesday, November 14, 2012 10:21:11 AM > Subject: Re: [Engine-devel] Managing permissions on network > > ----- Original Message ----- > > From: "Itamar Heim" <[email protected]> > > To: "Livnat Peer" <[email protected]> > > Cc: [email protected], "Michal Skrivanek" > > <[email protected]>, "Andrew Cathrow" <[email protected]>, > > "Gilad > > Chaplik" <[email protected]>, "Doron Fediuck" > > <[email protected]> > > 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. _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
