[Engine-devel] Managing permissions on network

[Itamar Heim]

On 11/14/2012 10:11 AM, Antoni Segura Puimedon wrote:
>
>
> ----- 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?

afaik, the concept of changing ldap scheme's to manage permissions from 
it is not very popular (unrelated to ovirt only).
it also means integration per ldap scheme.
but i'm open to hear otherwise from people using ldap to manage 
permission in ldap, and not just groups.

>
>>
>>>
>>> --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
>>