11:18 a.m.
----- Original Message -----
From: "Gilad Chaplik" <gchaplik(a)redhat.com>
To: "Itamar Heim" <iheim(a)redhat.com>
Cc: engine-devel(a)ovirt.org, "Michal Skrivanek" <mskrivan(a)redhat.com>,
"Andrew Cathrow" <acathrow(a)redhat.com>, "Doron
Fediuck" <dfediuck(a)redhat.com>, "Livnat Peer"
<lpeer(a)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(a)redhat.com>
> To: "Livnat Peer" <lpeer(a)redhat.com>
> Cc: engine-devel(a)ovirt.org, "Michal Skrivanek"
> <mskrivan(a)redhat.com>, "Andrew Cathrow"
<acathrow(a)redhat.com>,
> "Gilad
> Chaplik" <gchaplik(a)redhat.com>, "Doron Fediuck"
> <dfediuck(a)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.