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.
We should trust the event listener author as much as we trust the
servlet or script authors.
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
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
