You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Lars Trieloff <la...@trieloff.net> on 2007/12/21 16:29:59 UTC
Re: Event Scripting (was: Filter Scripting (was: POSTs and microjax))
Hi Felix,
I've been thinking about this, but do not see a solution right now.
The problem with the approach of executing the script with permissions
of the script owner (whoever this might be) is that in order to be
able to observe the whole repository, we have to give read access to
the whole repository to the script owner, which is another way of
creating a second superuser. So, instead of letting the script author
sneak in, we have to open the gates widely.
Lars
On 21.12.2007, at 14:15, Felix Meschberger wrote:
> Hi Lars,
>
> Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
>> Hi Felix,
>>
>> I think, we should protect the ability to install scripts or event
>> listeners, not limit the power of scripts or event listeners. You
>> could rephrase this example: Suppose somebody installs a GET.js
>> script
>> with bad-side effects and tricks the administrator or power-user into
>> requesting a corresponding resource: boom, the script is executed
>> with
>> power-user permissions.
>
> Sure, this is somewhat comparable - given that the power user is using
> the site :-) On the other hand, a power user may certainly maintain
> content, without even thinking about using possibly unsafe scripts:
> Compared to GET.js scripts, where he has some chance of not calling it
> by just not use the site, managing the content causes the scripts to
> be
> called.
>
> This _is_ different.
>
>> We should trust the event listener author as much as we trust the
>> servlet or script authors.
>
> No, because the initiation of the script execution is different: for
> servlets and other request handling script it is a willfull action of
> potentially causing some actions. When maintaining the content,
> there is
> no way of preventing such action - this is the power of observation.
>
> Regards
> Felix
>
>>
>> Lars
>>
>> On 21.12.2007, at 13:43, Felix Meschberger wrote:
>>
>>> Hi Lars,
>>>
>>> Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
>>>>>> The event is executed with the credentials of Event.getUserId().
>>>>>
>>>>> First it might not work. Of course, given the admin session, you
>>>>> might
>>>>> create a session of the desired user. Second, and more important:
>>>>> the
>>>>> Event.getUserId is the user name of the session which performed
>>>>> the
>>>>> changes causing the event.
>>>>
>>>> This is how it should behave. You change something in the
>>>> repository
>>>> and then you trigger the registered (high-level) event handlers.
>>>>
>>>>> Running the event handler as that user would
>>>>> open a backdoor wide open. So this is definitely a no-go. Sorry.
>>>>
>>>> I do not see the backdoor. Default permissions do still apply, and
>>>> you
>>>> as an authenticated user cannot inject a script that would be
>>>> executed
>>>> and the script cannot acquire a higher permission level.
>>>>
>>>> Can you describe a scenario where this backdoor is used?
>>>
>>> Consider a group EventListener is allowed to register event
>>> handlers.
>>> Members of this group have limited access rights to the repository.
>>> Now,
>>> the administrator (or some other power user) modifies data. The
>>> scripts
>>> posted by the EventListener users are now running as administrator
>>> (or
>>> as the other power user). And, boom, those EventListeners have more
>>> power than they are supposed to have ...
>>>
>>> Its just like a hidden and unintended sudo :-) One solution might be
>>> that script(s) run as the user owning the script - whatever "owner"
>>> means in JCR, as AFAIK there is no such thing specified and this
>>> would
>>> be implementation specific and therefore not securely leverageable.
>>>
>>> Another solution would be, to run the scripts as the "anonymous"
>>> user,
>>> provided that user has really limited rights.
>>>
>>> Regards
>>> Felix
>>>
>>
>> --
>> Lars Trieloff
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: Event Scripting (was: Filter Scripting (was: POSTs and
microjax))
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 21.12.2007, 16:29 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I've been thinking about this, but do not see a solution right now.
> The problem with the approach of executing the script with permissions
> of the script owner (whoever this might be) is that in order to be
> able to observe the whole repository, we have to give read access to
> the whole repository to the script owner, which is another way of
> creating a second superuser. So, instead of letting the script author
> sneak in, we have to open the gates widely.
Hmm, observe events and handling the events in case of scripting these
handlers are different things: There is a bundle observing the events
and in case of events will trigger the respective events. So we have an
issue of who will access the repository.
We could of course turn around and say, the scripts indicate what is
observed and hence the credentials of the user posting the script is
used to observe and run the scripts. So whatever rights the user posting
the script has defines, whether observation is at all possible and what
can be done.
This second solution would probably even make some sense. WDYT ?
Regards
Felix
>
> Lars
>
>
> On 21.12.2007, at 14:15, Felix Meschberger wrote:
>
> > Hi Lars,
> >
> > Am Freitag, den 21.12.2007, 14:02 +0100 schrieb Lars Trieloff:
> >> Hi Felix,
> >>
> >> I think, we should protect the ability to install scripts or event
> >> listeners, not limit the power of scripts or event listeners. You
> >> could rephrase this example: Suppose somebody installs a GET.js
> >> script
> >> with bad-side effects and tricks the administrator or power-user into
> >> requesting a corresponding resource: boom, the script is executed
> >> with
> >> power-user permissions.
> >
> > Sure, this is somewhat comparable - given that the power user is using
> > the site :-) On the other hand, a power user may certainly maintain
> > content, without even thinking about using possibly unsafe scripts:
> > Compared to GET.js scripts, where he has some chance of not calling it
> > by just not use the site, managing the content causes the scripts to
> > be
> > called.
> >
> > This _is_ different.
> >
> >> We should trust the event listener author as much as we trust the
> >> servlet or script authors.
> >
> > No, because the initiation of the script execution is different: for
> > servlets and other request handling script it is a willfull action of
> > potentially causing some actions. When maintaining the content,
> > there is
> > no way of preventing such action - this is the power of observation.
> >
> > Regards
> > Felix
> >
> >>
> >> Lars
> >>
> >> On 21.12.2007, at 13:43, Felix Meschberger wrote:
> >>
> >>> Hi Lars,
> >>>
> >>> Am Freitag, den 21.12.2007, 13:35 +0100 schrieb Lars Trieloff:
> >>>>>> The event is executed with the credentials of Event.getUserId().
> >>>>>
> >>>>> First it might not work. Of course, given the admin session, you
> >>>>> might
> >>>>> create a session of the desired user. Second, and more important:
> >>>>> the
> >>>>> Event.getUserId is the user name of the session which performed
> >>>>> the
> >>>>> changes causing the event.
> >>>>
> >>>> This is how it should behave. You change something in the
> >>>> repository
> >>>> and then you trigger the registered (high-level) event handlers.
> >>>>
> >>>>> Running the event handler as that user would
> >>>>> open a backdoor wide open. So this is definitely a no-go. Sorry.
> >>>>
> >>>> I do not see the backdoor. Default permissions do still apply, and
> >>>> you
> >>>> as an authenticated user cannot inject a script that would be
> >>>> executed
> >>>> and the script cannot acquire a higher permission level.
> >>>>
> >>>> Can you describe a scenario where this backdoor is used?
> >>>
> >>> Consider a group EventListener is allowed to register event
> >>> handlers.
> >>> Members of this group have limited access rights to the repository.
> >>> Now,
> >>> the administrator (or some other power user) modifies data. The
> >>> scripts
> >>> posted by the EventListener users are now running as administrator
> >>> (or
> >>> as the other power user). And, boom, those EventListeners have more
> >>> power than they are supposed to have ...
> >>>
> >>> Its just like a hidden and unintended sudo :-) One solution might be
> >>> that script(s) run as the user owning the script - whatever "owner"
> >>> means in JCR, as AFAIK there is no such thing specified and this
> >>> would
> >>> be implementation specific and therefore not securely leverageable.
> >>>
> >>> Another solution would be, to run the scripts as the "anonymous"
> >>> user,
> >>> provided that user has really limited rights.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> lars@trieloff.net
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>