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

Eli Mesika emesika at redhat.com
Thu Nov 22 23:10:28 UTC 2012



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

> 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

> 



More information about the Devel mailing list