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