[Engine-devel] Managing permissions on network

Antoni Segura Puimedon asegurap at redhat.com
Wed Nov 14 08:11:16 UTC 2012



----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Charlie" <medievalist at gmail.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, November 14, 2012 5:28:21 AM
> Subject: Re: [Engine-devel] Managing permissions on network
> 
> On 11/13/2012 09:57 PM, Charlie wrote:
> > Will any of these groups and/or permissions be drawn from LDAP?
> >
> > Frankly, system admins are not looking for yet another console to
> > manage permissions.
> 
> all users/groups come from LDAP.
> you just need to give permissions to these groups/users in ovirt.
> is that what you meant?

Would it be possible to somehow allow the admins to set permissions
on the LDAP console?

> 
> >
> > --Charlie
> >
> >
> > On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim <iheim at redhat.com>
> > wrote:
> >> 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?
> >>
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



More information about the Devel mailing list