Hello For sure not the easiest solution, but what about storing the application in a separate workspace from the content. If scripts were only executable in the application workspace, malicious attackers could maybe create a script in the content workspace, but it would not be possible to execute it.
Regards Julian On Thu, Apr 23, 2009 at 10:51 AM, Felix Meschberger <fmesc...@gmail.com> wrote: > Hi, > > Bertrand Delacretaz schrieb: >> Hi, >> >> On Wed, Apr 22, 2009 at 6:22 PM, Rory Douglas <rory.doug...@oracle.com> >> wrote: >>> Bertrand Delacretaz wrote: >>>> 2) Prevent legitimate scripts from messing up with the system >>> An variant of 2) just showed up in the "Accessing JCR" thread. Looks like >>> anyone that can upload a script can do the following: >>> >>> <sling:defineObjects/> >>> <% >>> SlingRepository repo = sling.getService(SlingRepository.class); >>> Session superSession = repo.loginAdministrative(null); >>> // and then do anything, like >>> superSession.getRootNode().remove(); >>> %> >> >> loginAdministrative is fine for trusted code, but you're right that we >> might want to restrict it. >> >> Not sure how to best approach this...what do people think? > > In terms of OPSGi and Java Security, the best approach would probably be > to guard this method by the SecurityManager and introduce a Permission > for this. > > Regards > Felix > -- Julian Sedding, Solution Engineer, Day Software AG email: julian.sedd...@day.com office: +41 61 226 98 92 http://www.day.com/ -- This message is a private communication. If you are not the intended recipient, please do not read, copy, or use it, and do not disclose it to others. Please notify the sender of the delivery error by replying to this message, and then delete it from your system. Thank you. The sender does not assume any liability for timely, trouble-free, complete, virus free, secure, error free or uninterrupted arrival of this e-mail. For verification please request a hard-copy version.
