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
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
