[xwiki-devs] Programming rights checks against top-level including doc or included doc
Hi, There is a major discrepancy in the way the programming rights are evaluated for the access to the privileged API from velocity compare to the right to execute groovy code. In the API, the right to access a priviledged API is evaluated against the sdoc in the current context, which is the document that contains the currently executed velocity code. Here is the code extracted from the current RightService implementation that does so: public boolean hasProgrammingRights(XWikiContext context) { XWikiDocument sdoc = (XWikiDocument) context.get("sdoc"); if (sdoc == null) sdoc = context.getDoc(); return hasProgrammingRights(sdoc, context); } In the XWikiGroovyRenderer, the right to render a groovy code is evaluated against the content doc, which is the top-level document that have directly or indirectly included the document that contains the evaluated groovy code. Here the excerpt from the code that made this check: if (! context.getWiki().getRightService().hasProgrammingRights(contentdoc, context)) { return content; } These are two opposed methods. As a direct consequence, a Sheet document (ie XWikiUserSheet) may be developed in velocity and use the priviledged API, but it is impossible to put a single line of Groovy in it, since the "instance" of the template documents that include the Sheet are usually created by users without programming rights. The debate is now, what is the original or current intend. Do you want: 1) to have a very secure situation, and therefore change hasProgrammingRights() implementation (why do we have a sdoc than?), or 2) to have a flexible, more responsible solution, were user having programming rights should take care not writing risky code, and therefore change the groovy renderer to accept groovy code based on contextdoc (sdoc in that place), so groovy and velocity gets the same access level ? The current situation is for me not acceptable, since it is a mix of 1) and 2) depending on the language, and there is no reason that the language influence the rights you have. Thanks for your comments... Denis -- Denis Gervalle SOFTEC sa http://www.softec.st
On Thu, Nov 27, 2008 at 12:37 PM, Denis Gervalle <[email protected]> wrote:
Hi,
There is a major discrepancy in the way the programming rights are evaluated for the access to the privileged API from velocity compare to the right to execute groovy code.
In the API, the right to access a priviledged API is evaluated against the sdoc in the current context, which is the document that contains the currently executed velocity code. Here is the code extracted from the current RightService implementation that does so:
public boolean hasProgrammingRights(XWikiContext context) { XWikiDocument sdoc = (XWikiDocument) context.get("sdoc"); if (sdoc == null) sdoc = context.getDoc(); return hasProgrammingRights(sdoc, context); }
In the XWikiGroovyRenderer, the right to render a groovy code is evaluated against the content doc, which is the top-level document that have directly or indirectly included the document that contains the evaluated groovy code. Here the excerpt from the code that made this check:
if (! context.getWiki().getRightService().hasProgrammingRights(contentdoc, context)) { return content; }
These are two opposed methods. As a direct consequence, a Sheet document (ie XWikiUserSheet) may be developed in velocity and use the priviledged API, but it is impossible to put a single line of Groovy in it, since the "instance" of the template documents that include the Sheet are usually created by users without programming rights.
The debate is now, what is the original or current intend. Do you want: 1) to have a very secure situation, and therefore change hasProgrammingRights() implementation (why do we have a sdoc than?), or 2) to have a flexible, more responsible solution, were user having programming rights should take care not writing risky code, and therefore change the groovy renderer to accept groovy code based on contextdoc (sdoc in that place), so groovy and velocity gets the same access level ?
The current situation is for me not acceptable, since it is a mix of 1) and 2) depending on the language, and there is no reason that the language influence the rights you have.
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
-- Denis Gervalle SOFTEC sa http://www.softec.st
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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. 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
-- Denis Gervalle SOFTEC sa http://www.softec.st
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
On Fri, Nov 28, 2008 at 3:39 PM, Denis Gervalle <[email protected]> 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.
We could start by just considering recursively: allow = contentdoc.programming || (sdoc.programming && sdoc.secure)
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.
We will need some votes here and i'm not strongly +1 or -1 on it, I'm just concerned about being less secure in general but since Velocity is already working the free way I guess we can enable it for groovy too.
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
-- Denis Gervalle SOFTEC sa http://www.softec.st
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (3)
-
Denis Gervalle -
Thomas Mortagne -
Vincent Massol