hi ian, sorry for the confusion. there are is no privilege to "execute" something in jcr. i am not even sure that they should be part of the repository since the repository is not going to execute things anyway.
i think if one has a tight coupling like between the os and the fs this may make sense, but i see the repo/sling coupling much looser so i would probably just go for the read privilege. the read privilege seems to be cause issue as far as i can tell not necessarily the execute privilege. right? regards, david On Tue, Jun 2, 2009 at 2:00 PM, Ian Boston <i...@tfd.co.uk> wrote: > So that marker should be and ACL containing an ACE with execute privilege > granted to the appropriate session. > I wasn't aware that there was such a privilege in the Jackrabbit > DefaultAccessManager or 283, > but I agree thats were it should be. > > On a practical note, > Unless DefaultAccessManager et al is going to be re-implemented for Sling, > then this should go back to Jackrabbit as DAM is heavily protected for > obvious reasons, and when I looked trying to extend the way in which > principals for a session were resolved, there didn't appear to be many (if > any) extension points available in DAM since registration of bits in the > compiled privileges bitmap > (o.a.j.core.security.authorization.PrivilegeRegistry.registerPrivilege) is > private (very) > > Ian > > On 2 Jun 2009, at 11:59, David Nuescheler wrote: > >> hi guys, >> >> i really think this should be dealt with, using proper repository >> access control. >> as soon as we start to let the application deal with security we need to >> worry about it every specific application, and become prone to >> "xyz-injection" >> similar to the problem that db's have with "sql injection". >> it becomes particularly tricky if you try to filter things out of the >> query results >> and the likes... >> >> my personal guidance would be to make the access control "tighter" in the >> sense that one would forbid read privileges to "/apps" and "/homes" for >> the >> anonymous user (in case that is not desired) and have the script execution >> use a session with appropriate privileges to read and execute. >> >> regards, >> david >> >> On Tue, Jun 2, 2009 at 12:50 PM, Ian Boston <i...@tfd.co.uk> wrote: >>> >>> Felix, >>> +1 >>> In addition, I would like to see a marker on the parent nodes that >>> designates the subtree as containing executable content. >>> >>> Then the special session can be used to execute the scripts, but only >>> after >>> it had checked to see the script is located in an "executable" subtree. >>> A suitably authorized user could read and write, >>> >>> Perhaps this already exists ? >>> Ian >>> On 2 Jun 2009, at 11:33, Felix Meschberger wrote: >>> >>>> Hi, >>>> >>>> John Crawford schrieb: >>>>> >>>>> I have been working with sling for quite some time and, of course, Day >>>>> products. One thing that I have been increasingly concerned with is >>>>> the >>>>> end >>>>> users ability to scrape all of the sites content and code with minimal >>>>> effort using the built in functionality of the SlingPostServlet. >>>> >>>> The Sling Get Servlet to be precise ;-) >>>> >>>>> >>>>> For Example: >>>>> >>>>> http://dev.day.com/discussion-groups/users.infinity.json >>>>> http://dev.day.com/discussion-groups/apps.infinity.json >>>> >>>> As Jukka said, you may employ access control to prevent this. >>>> >>>> But there is a glitch for the scripts located in /apps and /libs: >>>> Currently scripts are read from the repository using the session of the >>>> current user, that is the request user. >>>> >>>> So preventing access to >>>> >>>>> http://dev.day.com/discussion-groups/apps/mailingLists/mailingLists.jsp >>>> >>>> by simply denying read-access for the anonymous user actually prevents >>>> using the site at all. >>>> >>>> One solution to this problem could be to not load the scripts with the >>>> session of the current user but to use a special-purpose session (for >>>> example an admin session) to do this. >>>> >>>> This way, you may lock down /apps and /libs for general consumption but >>>> may still execute the scripts in there. >>>> >>>> WDYT ? >>>> >>>> Regards >>>> Felix >>>> >>>> >>>> (this >>>>> >>>>> one really disturbs me) >>>>> >>>>> So far, my solution has been to provide a proxy (namely Apache2) in >>>>> front >>>>> of >>>>> sling to filter out any undesired requests. Seems to work. But, by >>>>> doing >>>>> this, it takes way what is so cool about Sling. I have reported to Day >>>>> Support numerous times, but they don't seem too concerned about it. >>>>> But >>>>> for >>>>> sites where the content is critical or where we require users to pay >>>>> for >>>>> our >>>>> content, it is very important to us. >>>>> >>>>> Is there a better way to handle this? >>>>> >>>>> Please let me know your thoughts. >>>>> >>>>> Respectfully, >>>>> John >>>>> >>> >>> >> >> >> >> -- >> David Nuescheler >> Chief Technology Officer >> mailto: david.nuesche...@day.com >> >> web: http://www.day.com/ http://dev.day.com >> twitter: @daysoftware > > -- David Nuescheler Chief Technology Officer mailto: david.nuesche...@day.com web: http://www.day.com/ http://dev.day.com twitter: @daysoftware
