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

----- Original Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Christopher Morrissey" <Christopher.Morrissey(a)netapp.com&gt; > Cc: "Eli Mesika" <emesika(a)redhat.com&gt;, "engine-devel" <engine-devel(a)ovirt.org&gt; > 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 ?

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