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

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?

this is only for admin roles, not user roles. what's the risk in allowing admins to inject external events?