On 23 Jun 2009, at 09:42, Felix Meschberger wrote:
Hi,
Dominik Süß schrieb:
Wouldn't this take us the ability to restrict allowed actions by
taking
reading rights of the scriptlocation by ACLs?
How would you solve restriction on scriptaccess?
What exact problem do you want to solve with the restriction on script
access ? Do you have some kind of "x-bit" in mind ? The repository
itself has no support for (and cannot support) this kind of permission
itself.
As Bertrand already said, lets ignore this for now and add it later
(proabbly to the scripting infrastructure in the scripting/core
bundle).
Although Sling might choose to ignore this, I/we (sakai) are going to
need to do something since all our users have write access to the
repo, and at least 10% of them are Computer Science first year
students just itching to prove their prowess by hacking/defacing an
institutional system :)
If I understand the issue correctly, if I have write access to the
repo, I can upload a JSP file and get access to all the classes in the
JVM, and using reflection (as in AccessControlUtils) I circumvent any
bundle boundaries.
There was talk at some point in using a special principal to read the
script files for execution, so that a standard JCR ACL could control
what could be loaded for execution. That would work for us... but we
wont be able to ignore this issue.
Happy to look into a patch if that would help.
Ian
Regards
Felix
Best regards,
Dominik
On Mon, Jun 22, 2009 at 9:20 PM, Carsten Ziegeler <[email protected]
>wrote:
Another minor issue are the helper methods of the JcrResourceUtil
class
(the getResourceSuperType, resourceTypeToPath methods). I think we
can
make them completly JCR free and move them to the ResourceUtil
class in
the API.
Carsten
Carsten Ziegeler wrote:
Hi,
I'm currently working on improving the script resolution in terms
of
performance.
While looking at how it works today, I've discovered two
problematic
points:
1) Currently the scripts are searched by using the session of the
current request. Now, I think using the user session to search the
script is wrong. The content, the user requests, is already
retrieved
with the user session and its the content (or the acl's on the
content)
who define if the user is allowed to access something.
The script should always be executable (and I'm speaking of
execution
not reading, writing etc.) for any user. This also matches the
current
handling for scripts which are not stored in the repository like
the
servlets or scripts contained in bundle resources.
Therefore I suggest to change the script resolution to use the
admin
session.
Btw, this would also make caching the script resolution easier as
the
current approach requires the caching of the script resolution to
be a
per user cache. With the changes from above the cache can be
global.
2) Resource events
We need to implement https://issues.apache.org/jira/browse/SLING-944
and
some extension of this to properly update the cache if scripts are
changed, added removed. As scripts can be coming from any data
source
(jcr, file system, bundle, database etc.) we need a generic
mechanism
here.
For now I think we could start with OSGi events for
- Resource added, removed, changed
- Resource Provider added, removed
WDYT?
Carsten
--
Carsten Ziegeler
[email protected]
