On Nov 28, 2008, at 3:39 PM, Denis Gervalle wrote: > Nice idea, telling the wiki that the script is secure enought to be > included from insecure document seems to be a very secure solution. > But you should take care of deep inclusion, and what would be the > logic ? B is set secure and have programming rights, A does not have > programming rigths, C does and is insecure, do you consider that C has > programming rights when included by A through B ? > That could be nice, imagine, C is a generic class runner, B choose the > class, A is the user document. If A were able to include C, any class > could be loaded, but through B, only those that B decide upon. Yes > this could definitely be a nice solution, but it has to be design > properly. > > However, if you should go to this complexity, since we have supported > the less secure option for long now in velocity, and this does not > seems to have receive a bad feedback. So why not just treat groovy as > we treat velocity since the beginning ? > Moreover, if I were to chose, since velocity programming does not > require programming rights, I feel it is more sensible to get > influenced than groovy could be, if you respect some simple security > rules.
I also would like to see Velocity and Groovy at the same level (and all scripts too) with 2 APIs: one that doesn't require programming rights and one that would require programming rights. We would need to protect Groovy scripts (for ex using a custom Java Security Policy) so that they cannot access the file system, sockets, threads, etc. Thanks -Vincent > Denis > PS: I wonder if macro written in groovy requires programming rights... > > On 28 nov. 08, at 15:13, Thomas Mortagne wrote: >> >> I totally agreed than we can't have two way of managing programming >> rights here. >> >> But I'm not sure about what is the good answer. >> >> Use containing document to test programing rights: >> * Cons: >> - security: it means the groovy script has to be very careful of >> what it is doing because a document which include it can influence it >> be providing its and own objects. >> >> * Pros: >> - it makes possible to use groovy on private api for Sheet pages >> like users profiles sheet page in Deni's use case >> >> I see another solution: add some document's metadata indicating if >> the >> script can be included by some other document meaning that the >> programming rights can be tester on the included document or not. It >> would be false by default. This way someone with programming right >> can >> do some scipt in a page and explicitly indicate this can be used by >> non-programming document authors. >> >>> Thanks for your comments... >>> >>> Denis _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
