[Engine-devel] Design review summary for 3.2 - adding support for External Events

[Itamar Heim]

On 11/23/2012 01:10 AM, Eli Mesika wrote:
>
>
> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Christopher Morrissey" <Christopher.Morrissey at netapp.com>
>> Cc: "Eli Mesika" <emesika at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Thursday, November 22, 2012 8:35:56 AM
>> Subject: Re: [Engine-devel] Design review summary for 3.2 - adding support for	External Events
>>
>> On 11/20/2012 04:07 PM, Morrissey, Christopher wrote:
>> ...
>>
>>>>>> Hi Eli,
>>>>>>
>>>>>> I've perused the design and it looks very good for the purpose
>>>>>> of
>>>>>> adding events to the log as back end tasks on the NetApp VSC are
>>>>>> started and complete.
>>>>>>
>>>>>> I do have one question. As part of the new UI plugin framework
>>>>>> that
>>>>>> Vojtech is working on he added the capability to retrieve a
>>>>>> session
>>>>>> ID that will be used outside of the oVirt engine to invoke REST
>>>>>> API
>>>>>> calls. I'm assuming this session would have the same role as the
>>>>>> user that is currently logged in.
>>>>>>
>>>>>> According to the event log design, only the Super user will have
>>>>>> permissions to add events by default. This would mean that if
>>>>>> anyone
>>>>>> other than the super user is logged in and performing any tasks
>>>>>> through the NetApp plugin, the server side of the VSC will
>>>>>> likely
>>>>>> not be able to log events. This could be confusing for users as
>>>>>> sometimes they see events showing up giving them information on
>>>>>> the
>>>>>> task progress and sometimes they don't depending on the role
>>>>>> logged
>>>>>> in.
>>>>>>
>>>>>> Would it make sense to allow all roles to log events by default?
>>>>>> I'm
>>>>>> not sure what security problems would arise given that it is
>>>>>> just a
>>>>>> log and they would be tagged as external events.
>>>>>
>>>>> Hi Christopher, our security model implies a black-list,
>>>>
>>>> oops, I meant white-list of course ....
>>>>
>>>
>>> That's what I figured. :)
>>>
>>>> so, I don;t
>>>>> think this is possible
>>>>> But still, a super-user can of course give the permission to add
>>>>> new
>>>>> events to all Roles in the system and you will have the same
>>>>> result.
>>>>> Does that make sense ?
>>>>>
>>>
>>> That does make sense. We'll likely just try to use the API to log
>>> events when starting a task and if we receive an error we can
>>> bubble that up to the user letting them know that they need to
>>> either get the right permission or accept that they won't get
>>> messages in the oVirt log while the task completes.
>>
>> Eli - not that the design includes checking for permissions on
>> objects,
>> why wouldn't we add this permission (ActionGroup) to other admin
>> roles
>> as well?
>
> You mean in DB upgrade , right ?

well, in design, but then yes, as part of upgrade to fix the relevant 
pre-defined roles

>
>> this is only for admin roles, not user roles. what's the risk in
>> allowing admins to inject external events?
>
> IIUC , you are right , no risk
>
>>