5 Aug
2008
5 Aug
'08
9:36 a.m.
Hello,
Do you foresee a special syntax for groovy scripts as you already have for
velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic"
part of scripts in separated documents and to be able to import them in
other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define
some groovy classes in a page and tell "this is groovy code which is not
"WIKI-renderable" as is".
Then we could simply import/include this script in another page (just paste
the code without any rendering) using something like
#include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to
include some part of scripts.
Existing #includeXXX macros always render the content and here I only want
to paste a script from somewhere else (xwiki.getDocument("").getContent() in
fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and
the #include macro for the same groovy "document". For the time being, one
need to use the trick
/* groovygroovy #* */
/* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other
function can interprete this tricky syntax.
best regards
Pascal
5 Aug
5 Aug
9:49 a.m.
Hi Pascal,
A {{groovy}} macro is planned. However what you seem to be asking for
might cause some security issues.
Groovy needs to be limited to "Programmer" authors so we are trying to
avoid complex includes of groovy code that could lead to inject groovy code.
Could you give a use case with an example of what you would like to
achieve using groovy ?
Is it something like that
----
text text text
{{groovy}}
{{include:MySpace.GroovyDoc}}
other groovy code
{{groovy}}
text text test
----
And MySpace.GroovyDoc is a pure text file containing groovy code ?
If we implement this it would mean checking that MySpace.GroovyDoc and
the current page are own by priviledge users. So the include would need
to know it is in the context of a {{groovy}} macro.
It also depends when the {{groovy}} macro runs and if we allow the
{{include}} to run in this context.
Ludovic
Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have for
velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some "generic"
part of scripts in separated documents and to be able to import them in
other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to define
some groovy classes in a page and tell "this is groovy code which is not
"WIKI-renderable" as is".
Then we could simply import/include this script in another page (just paste
the code without any rendering) using something like
#include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to
include some part of scripts.
Existing #includeXXX macros always render the content and here I only want
to paste a script from somewhere else (xwiki.getDocument("").getContent() in
fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy" and
the #include macro for the same groovy "document". For the time being, one
need to use the trick
/* groovygroovy #* */
/* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other
function can interprete this tricky syntax.
best regards
Pascal
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
10:10 a.m.
Hello,
please see below...
On Tue, Aug 5, 2008 at 9:49 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Hi Pascal,
A {{groovy}} macro is planned. However what you seem to be asking for
might cause some security issues.
Groovy needs to be limited to "Programmer" authors so we are trying to
avoid complex includes of groovy code that could lead to inject groovy
code.
You're right about the security issue!
I was only thinking about my coding issue but not about this important issue
:)
Could you give a use case with an example of what you would like to
achieve using groovy ?
Is it something like that
----
text text text
{{groovy}}
{{include:MySpace.GroovyDoc}}
other groovy code
{{groovy}}
text text test
----
it could be something like that in an ideal world
And MySpace.GroovyDoc is a pure text file containing groovy code ?
If we implement this it would mean checking that MySpace.GroovyDoc and
the current page are own by priviledge users. So the include would need
to know it is in the context of a {{groovy}} macro.
It also depends when the {{groovy}} macro runs and if we allow the
{{include}} to run in this context.
I agree with you, this is not simple in this context.
Anyway, I have a question:
Groovy is programmed by a programmer with special rights but it can be
executed by anyone. Am I right? (apparently this is the default behaviour I
can see)
What prevents anyone with edit rights to add $xwiki.parseGroovy in his
velocity script (do you need programming rights for this) ?
Moreover if you put in a document something like this:
{pre}
<%
I do some groovy things
%>
{/pre}
then in another one
you put
# some velocity things
$xwiki.getDocument("GroovyDoc").getContent()
# some other things
Is the groovy simply injected here and executed when someone with default
rights access the last doc? (Apparently with default rights, that's what
happened... I may have missed something)
Pascal
Ludovic
Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already have
for
velocity using {{velocity}} with some more
features?
My idea is to be able to code cleanly using groovy and to put some
"generic"
part of scripts in separated documents and to be
able to import them in
other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or to
define
some groovy classes in a page and tell "this
is groovy code which is not
"WIKI-renderable" as is".
Then we could simply import/include this script in another page (just
paste
the code without any rendering) using something
like
#include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to
include some part of scripts.
Existing #includeXXX macros always render the content and here I only
want
to paste a script from somewhere else
(xwiki.getDocument("").getContent()
in
fact)
Moreover the idea would be also to allow using both "xwiki.parseGroovy"
and
the #include macro for the same groovy
"document". For the time being,
one
need to use the trick
/* groovygroovy #* */
/* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no other
function can interprete this tricky syntax.
best regards
Pascal
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:21 a.m.
Pascal Voitot wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
I agree with you, this is not simple in this context.
Anyway, I have a question:
Groovy is programmed by a programmer with special rights but it can be
executed by anyone. Am I right? (apparently this is the default behaviour I
can see)
What prevents anyone with edit rights to add $xwiki.parseGroovy in his
velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the
responsibility of the programmer to do a groovy script that is secure or
to do himself checkProgrammingRights in his code. If he does then the
page doing parseGroovyFromPage needs programming rights.
parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like
this:
{pre}
<%
I do some groovy things
%>
{/pre}
then in another one
you put
# some velocity things
$xwiki.getDocument("GroovyDoc").getContent()
# some other things
Is the groovy simply injected here and executed when someone with default
rights access the last doc? (Apparently with default rights, that's what
happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be
parsed. Mixing velocity with groovy is dangerous, because You could beat
the groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage.
Ludovic
10:52 a.m.
So, this is the responsability of the programmer to control the access to
his code... This is quite free but requires a good knowledge about what you
do...
(I wonder wether providing the {{include}} macros would bring much more
dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to prevent
groovy parser from plundering memory?
I need to think about all of this because Groovy integrated in xwiki with
velocity also is so much powerful to my mind that it might be worth digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Pascal Voitot wrote:
I agree with you, this is not simple in this context.
Anyway, I have a question:
Groovy is programmed by a programmer with special rights but it can be
executed by anyone. Am I right? (apparently this is the default behaviour
I
can see)
What prevents anyone with edit rights to add $xwiki.parseGroovy in his
velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the
responsibility of the programmer to do a groovy script that is secure or
to do himself checkProgrammingRights in his code. If he does then the
page doing parseGroovyFromPage needs programming rights.
parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like
this:
{pre}
<%
I do some groovy things
%>
{/pre}
then in another one
you put
# some velocity things
$xwiki.getDocument("GroovyDoc").getContent()
# some other things
Is the groovy simply injected here and executed when someone with default
rights access the last doc? (Apparently with default rights, that's what
happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be
parsed. Mixing velocity with groovy is dangerous, because You could beat
the groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage. Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10:55 a.m.
Pascal Voitot wrote:
So, this is the responsability of the programmer to
control the access to
his code... This is quite free but requires a good knowledge about what you
do...
(I wonder wether providing the {{include}} macros would bring much more
dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to prevent
groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once).
It also allows good separation between priviledge code and user code.
Programmers can write complex code + velocity macros, and less
experienced users can use these macros or classes.
Ludovic
I need to think about all of this because Groovy
integrated in xwiki with
velocity also is so much powerful to my mind that it might be worth digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Pascal Voitot wrote:
I agree with you, this is not simple in this
context.
Anyway, I have a question:
Groovy is programmed by a programmer with special rights but it can be
executed by anyone. Am I right? (apparently this is the default behaviour
I
can see)
What prevents anyone with edit rights to add $xwiki.parseGroovy in his
velocity script (do you need programming rights for this) ?
The groovy script needs to be own by a programmer. This is the
responsibility of the programmer to do a groovy script that is secure or
to do himself checkProgrammingRights in his code. If he does then the
page doing parseGroovyFromPage needs programming rights.
parseGroovyFromString always needs programming rights.
Moreover if you put in a document something like
this:
{pre}
<%
I do some groovy things
%>
{/pre}
then in another one
you put
# some velocity things
$xwiki.getDocument("GroovyDoc").getContent()
# some other things
Is the groovy simply injected here and executed when someone with default
rights access the last doc? (Apparently with default rights, that's what
happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be
parsed. Mixing velocity with groovy is dangerous, because You could beat
the groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:08 a.m.
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Pascal Voitot wrote:
Finally, this might not be a bad choice even if it brings some
constraints...
Do you intend to write some precise docs about this because this is not
really clear without wandering for some time...
one last question (I'm lazy so I prefer asking than thinking ;)):
Where do you advise to put user.hasProgrammingRight() ?
If you don't put it in the doc called by parseGroovy, I don't see the
interest...
Then do you put it outside the groovy part using velocity:
if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is not
clever due to the mixing of velocity with groovy)
or in the groovy part ?
In both case, it will generate an exception as parseGroovy will fail. How to
have a clean "you don't have access to this content"
Pascal
So, this is the responsability of the programmer
to control the access to
his code... This is quite free but requires a good knowledge about what
you
do...
(I wonder wether providing the {{include}} macros would bring much more
dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to
prevent
groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once).
It also allows good separation between priviledge code and user code.
Programmers can write complex code + velocity macros, and less
experienced users can use these macros or classes.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I need to think about all of this because Groovy
integrated in xwiki with
velocity also is so much powerful to my mind that it might be worth
digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <ludovic(a)xwiki.org>
wrote:
> Pascal Voitot wrote:
>
>> I agree with you, this is not simple in this context.
>>
>> Anyway, I have a question:
>> Groovy is programmed by a programmer with special rights but it can be
>> executed by anyone. Am I right? (apparently this is the default
behaviour
>>
> I
>
>> can see)
>> What prevents anyone with edit rights to add $xwiki.parseGroovy in his
>> velocity script (do you need programming rights for this) ?
>>
>>
> The groovy script needs to be own by a programmer. This is the
> responsibility of the programmer to do a groovy script that is secure or
> to do himself checkProgrammingRights in his code. If he does then the
> page doing parseGroovyFromPage needs programming rights.
> parseGroovyFromString always needs programming rights.
>
>
>> Moreover if you put in a document something like this:
>>
>> {pre}
>> <%
>> I do some groovy things
>> %>
>> {/pre}
>>
>> then in another one
>> you put
>>
>> # some velocity things
>> $xwiki.getDocument("GroovyDoc").getContent()
>> # some other things
>>
>> Is the groovy simply injected here and executed when someone with
default
>> rights access the last doc? (Apparently
with default rights, that's
what
happened... I may have missed something)
The page needs to be owned by an priviledge user for the groovy to be
parsed. Mixing velocity with groovy is dangerous, because You could beat
the groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:35 a.m.
I'm a bit stupid...
In a previous mail, you told that the checkProgrammingRights should be done
in the code directly...
Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact...
Can users access a document calling $xwiki.parseGroovy without programming
rights and execute the groovy script? (apparently yes in my tests)
Or do you strongly advise programmers to prevent users from using groovy
scripts when they don't have programming rights using
checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
On Tue, Aug 5, 2008 at 11:08 AM, Pascal Voitot
<pascal.voitot.dev(a)gmail.com>wrote;wrote:
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Pascal Voitot wrote:
Finally, this might not be a bad choice even if it brings some
constraints...
Do you intend to write some precise docs about this because this is not
really clear without wandering for some time...
one last question (I'm lazy so I prefer asking than thinking ;)):
Where do you advise to put user.hasProgrammingRight() ?
If you don't put it in the doc called by parseGroovy, I don't see the
interest...
Then do you put it outside the groovy part using velocity:
if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is not
clever due to the mixing of velocity with groovy)
or in the groovy part ?
In both case, it will generate an exception as parseGroovy will fail. How
to have a clean "you don't have access to this content"
Pascal
So, this is the responsability of the programmer
to control the access
to
his code... This is quite free but requires a
good knowledge about what
you
do...
(I wonder wether providing the {{include}} macros would bring much more
dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to
prevent
groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once).
It also allows good separation between priviledge code and user code.
Programmers can write complex code + velocity macros, and less
experienced users can use these macros or classes.
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I need to think about all of this because Groovy
integrated in xwiki
with
velocity also is so much powerful to my mind that
it might be worth
digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <ludovic(a)xwiki.org>
wrote:
> Pascal Voitot wrote:
>
>> I agree with you, this is not simple in this context.
>>
>> Anyway, I have a question:
>> Groovy is programmed by a programmer with special rights but it can be
>> executed by anyone. Am I right? (apparently this is the default
behaviour
>>
> I
>
>> can see)
>> What prevents anyone with edit rights to add $xwiki.parseGroovy in his
>> velocity script (do you need programming rights for this) ?
>>
>>
> The groovy script needs to be own by a programmer. This is the
> responsibility of the programmer to do a groovy script that is secure
or
> to do himself checkProgrammingRights in his
code. If he does then the
> page doing parseGroovyFromPage needs programming rights.
> parseGroovyFromString always needs programming rights.
>
>
>> Moreover if you put in a document something like this:
>>
>> {pre}
>> <%
>> I do some groovy things
>> %>
>> {/pre}
>>
>> then in another one
>> you put
>>
>> # some velocity things
>> $xwiki.getDocument("GroovyDoc").getContent()
>> # some other things
>>
>> Is the groovy simply injected here and executed when someone with
default
>> rights access the last doc? (Apparently
with default rights, that's
what
>> happened... I may have missed something)
>>
>>
> The page needs to be owned by an priviledge user for the groovy to be
> parsed. Mixing velocity with groovy is dangerous, because You could
beat
the
groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage.
Ludovic
>
>
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:52 p.m.
Let's take an example
public class Groovy {
public boolean delete(String docname, Context context) {
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
This script is a priviledge script and will use the underlying xwiki
api. This means that no rights check are performed on the call to
xwiki2.deleteDocument.
If you let this class in your wiki, any use can use parseGroovyFromPage
to instanciate the class and call delete() and delete any page
regardeless of the user rights.
To fix this you do:
public class Groovy {
public boolean delete(String docname, Context context) {
if (!context.hasProgrammingRights())
return false;
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
If the author of the page making the call to parseGroovyFromPage and
deleteDocument is not a "programmer" then the call fails.
For example if the page is
$xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context)
Then any use can access the page setup by the programmer to delete it's
own page.
If the user tries to change the page to replace by $context.user by any
page, then the programmers right is revoked and the call fails
Therefore you delete() function is secure.
Ludovic
Pascal Voitot wrote:
I'm a bit stupid...
In a previous mail, you told that the checkProgrammingRights should be done
in the code directly...
Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact...
Can users access a document calling $xwiki.parseGroovy without programming
rights and execute the groovy script? (apparently yes in my tests)
Or do you strongly advise programmers to prevent users from using groovy
scripts when they don't have programming rights using
checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
11:22 p.m.
see below
On Tue, Aug 5, 2008 at 6:52 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
Let's take an example
public class Groovy {
public boolean delete(String docname, Context context) {
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
This script is a priviledge script and will use the underlying xwiki
api. This means that no rights check are performed on the call to
xwiki2.deleteDocument.
If you let this class in your wiki, any use can use parseGroovyFromPage
to instanciate the class and call delete() and delete any page
regardeless of the user rights.
To fix this you do:
public class Groovy {
public boolean delete(String docname, Context context) {
if (!context.hasProgrammingRights())
return false;
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
If the author of the page making the call to parseGroovyFromPage and
deleteDocument is not a "programmer" then the call fails.
For example if the page is
$xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context)
Then any use can access the page setup by the programmer to delete it's
own page.
If the user tries to change the page to replace by $context.user by any
page, then the programmers right is revoked and the call fails
Therefore you delete() function is secure.
That's what I understood at first sight... (and why don't you include this
small doc in xwiki.org doc to help people understand what they should do or
not...)
My second idea was: why not prevent the groovy parsing and instantiation
when you don't have the rights?(it would spare some memory and process time)
Thank you for your explanation
Pascal
Ludovic
Pascal Voitot wrote:
I'm a bit stupid...
In a previous mail, you told that the checkProgrammingRights should be
done
in the code directly...
Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact...
Can users access a document calling $xwiki.parseGroovy without
programming
rights and execute the groovy script? (apparently
yes in my tests)
Or do you strongly advise programmers to prevent users from using groovy
scripts when they don't have programming rights using
checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:52 p.m.
If you have a few minutes to space, don't hesitate to transform this
into xwiki.org docs..
That would help a lot
Ludovic
Pascal Voitot wrote:
see below
On Tue, Aug 5, 2008 at 6:52 PM, Ludovic Dubost <ludovic(a)xwiki.org> wrote:
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Let's take an example
public class Groovy {
public boolean delete(String docname, Context context) {
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
This script is a priviledge script and will use the underlying xwiki
api. This means that no rights check are performed on the call to
xwiki2.deleteDocument.
If you let this class in your wiki, any use can use parseGroovyFromPage
to instanciate the class and call delete() and delete any page
regardeless of the user rights.
To fix this you do:
public class Groovy {
public boolean delete(String docname, Context context) {
if (!context.hasProgrammingRights())
return false;
def xwiki = context.getWiki();
def xwiki2 = xwiki.xWiki;
def context2 = context.context;
xwiki2.deleteDocument(docName, context2);
return true;
}
}
If the author of the page making the call to parseGroovyFromPage and
deleteDocument is not a "programmer" then the call fails.
For example if the page is
$xwiki.parseGroovyFromPage("..").deleteDocument($context.user,$context)
Then any use can access the page setup by the programmer to delete it's
own page.
If the user tries to change the page to replace by $context.user by any
page, then the programmers right is revoked and the call fails
Therefore you delete() function is secure.
That's what I understood at first sight... (and why don't you include this
small doc in xwiki.org doc to help people understand what they should do or
not...)
My second idea was: why not prevent the groovy parsing and instantiation
when you don't have the rights?(it would spare some memory and process time)
Thank you for your explanation
Pascal
Ludovic
Pascal Voitot wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I'm a bit stupid...
In a previous mail, you told that the checkProgrammingRights should be
done
in the code directly...
Is it true?
In fact, I'm a bit lost reading everything again :)
The programmer programs the groovy script, that's a fact...
Can users access a document calling $xwiki.parseGroovy without
programming
rights and execute the groovy script? (apparently
yes in my tests)
Or do you strongly advise programmers to prevent users from using groovy
scripts when they don't have programming rights using
checkProgrammingRights?
Sorry for disturbing you ;)
PAscal
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:17 p.m.
Pascal Voitot wrote:
On Tue, Aug 5, 2008 at 10:55 AM, Ludovic Dubost
<ludovic(a)xwiki.org> wrote:
Pascal Voitot wrote:
Finally, this might not be a bad choice even if it brings some
constraints...
Do you intend to write some precise docs about this because this is not
really clear without wandering for some time...
one last question (I'm lazy so I prefer asking than thinking ;)):
Where do you advise to put user.hasProgrammingRight() ?
If you don't put it in the doc called by parseGroovy, I don't see the
interest...
So, this is the responsability of the programmer
to control the access to
his code... This is quite free but requires a good knowledge about what
you
do...
(I wonder wether providing the {{include}} macros would bring much more
dangerous issues in this case apart from the memory issue you evoked)
Does parseGroovy takes care about not duplicating script parsing to
prevent
groovy parser from plundering memory?
Yes parseGroovy is cached (the class is only compiled once).
It also allows good separation between priviledge code and user code.
Programmers can write complex code + velocity macros, and less
experienced users can use these macros or classes.
Then do you put it outside the groovy part using
velocity:
if($user.hasProgrammingRights) { /* groovy part */ } (maybe this is no
clever due to the mixing of velocity with groovy)
This would not be secure
or in the groovy part ?
It should be inside the page with the Groovy class. Any function that
bypasses rights need to have it's own right check
Ludovic
In both case, it will generate an exception as
parseGroovy will fail. How to
have a clean "you don't have access to this content"
Pascal
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Ludovic
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I need to think about all of this because Groovy
integrated in xwiki with
velocity also is so much powerful to my mind that it might be worth
digging
into it...
Pascal
On Tue, Aug 5, 2008 at 10:21 AM, Ludovic Dubost <ludovic(a)xwiki.org>
wrote:
> Pascal Voitot wrote:
>
>
>> I agree with you, this is not simple in this context.
>>
>> Anyway, I have a question:
>> Groovy is programmed by a programmer with special rights but it can be
>> executed by anyone. Am I right? (apparently this is the default
>>
behaviour
> I
>
>
>> can see)
>> What prevents anyone with edit rights to add $xwiki.parseGroovy in his
>> velocity script (do you need programming rights for this) ?
>>
>>
>>
> The groovy script needs to be own by a programmer. This is the
> responsibility of the programmer to do a groovy script that is secure or
> to do himself checkProgrammingRights in his code. If he does then the
> page doing parseGroovyFromPage needs programming rights.
> parseGroovyFromString always needs programming rights.
>
>
>
>> Moreover if you put in a document something like this:
>>
>> {pre}
>> <%
>> I do some groovy things
>> %>
>> {/pre}
>>
>> then in another one
>> you put
>>
>> # some velocity things
>> $xwiki.getDocument("GroovyDoc").getContent()
>> # some other things
>>
>> Is the groovy simply injected here and executed when someone with
>>
default
>> rights access the last doc? (Apparently
with default rights, that's
>>
what
>
happened... I may have missed something)
>
>
>
The page needs to be owned by an priviledge user for the groovy to be
parsed. Mixing velocity with groovy is dangerous, because You could beat
the groovy cache if the script passed to groovy is different on every
evaluation. This can lead to high memory usage.
Ludovic
>
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:09 p.m.
Hi Pascal,
Let's analyse the way it currently works in the new rendering. Let's
take velocity first:
{{velocity}}
... velocity code here...
{{include document="..."/}}
... velocity code here...
{{/velocity}}
These are the steps that are executed:
1/ The whole text is parsed using the wiki syntax parser. This
generates an XDOM object containing a single MacroBlock wrapping the
velocity macro.
2/ When it's rendered, the Macroblock executes, finds the velocity
macro and executes it.
3/ velocity is run on the part inside the velocity macro.
4/ the wiki syntax parser is then executed on the part on which
velocity has been executed. This means that the macros inside the
velocity block are now executed. This means the include macro is
executed. If it contains velocity code it'll be parsed as a standard
paragraph text and all special characters are escaped. So if you have
velocity script in the document you're including for example it'll be
displayed as is without being executed. You'd need to have the
velocity macro wrapping it in the document to include for it to be
executed.
Thus I don't think we have any security issue here.
Now let's look at groovy. The macro is not written yet but I think
it'll work like what is described below. First the following is NOT
valid:
{{groovy}}
... groovy code here...
{{include document="..."/}}
... groovy code here...
{{/velocity}}
Groovy will execute on the part inside the groovy macro and will fail
on the {{include}} part I think since it's not valid groovy syntax.
Now the groovy code could do something like out.println("{{include
document='...'/}}")
In this case the resulting macro will get executed (since the logic is
that the new rendering uses the MacroTransformation to execute the
macros and this transformation continues to execute till there's no
more macro to execute).
Now if the included document contains groovy code not inside a groovy
macro nothing will happen and the code will be printed as standard
text (no groovy execution). If it's inside a groovy macro then it'll
get executed but only once since the groovy macro in the page doing
the include will have already executed.
To summarize, I think the fact that outside macros execute before
nested macros prevents dangerous things to happen in general. Now I
haven't analysed all cases yet so if you see something dangerous
please let me know so that I can fix it while it's possible.
To answer your question Pascal, you would write:
{{groovy}}
... some groovy code...
{{/groovy}}
{{include document="... page containing a groovy macro..."
context="current"/}}
Let me know if I missed something.
Thanks
-Vincent
On Aug 5, 2008, at 9:36 AM, Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already
have for
velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some
"generic"
part of scripts in separated documents and to be able to import them
in
other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or
to define
some groovy classes in a page and tell "this is groovy code which is
not
"WIKI-renderable" as is".
Then we could simply import/include this script in another page
(just paste
the code without any rendering) using something like
#include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to
include some part of scripts.
Existing #includeXXX macros always render the content and here I
only want
to paste a script from somewhere else
(xwiki.getDocument("").getContent() in
fact)
Moreover the idea would be also to allow using both
"xwiki.parseGroovy" and
the #include macro for the same groovy "document". For the time
being, one
need to use the trick
/* groovygroovy #* */
/* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no
other
function can interprete this tricky syntax.
best regards
Pascal
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:29 p.m.
see below
On Tue, Aug 5, 2008 at 5:09 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Pascal,
Let's analyse the way it currently works in the new rendering. Let's
take velocity first:
{{velocity}}
... velocity code here...
{{include document="..."/}}
... velocity code here...
{{/velocity}}
These are the steps that are executed:
1/ The whole text is parsed using the wiki syntax parser. This
generates an XDOM object containing a single MacroBlock wrapping the
velocity macro.
2/ When it's rendered, the Macroblock executes, finds the velocity
macro and executes it.
3/ velocity is run on the part inside the velocity macro.
4/ the wiki syntax parser is then executed on the part on which
velocity has been executed. This means that the macros inside the
velocity block are now executed. This means the include macro is
executed. If it contains velocity code it'll be parsed as a standard
paragraph text and all special characters are escaped. So if you have
velocity script in the document you're including for example it'll be
displayed as is without being executed. You'd need to have the
velocity macro wrapping it in the document to include for it to be
executed.
Thus I don't think we have any security issue here.
Now let's look at groovy. The macro is not written yet but I think
it'll work like what is described below. First the following is NOT
valid:
{{groovy}}
... groovy code here...
{{include document="..."/}}
... groovy code here...
{{/velocity}}
Groovy will execute on the part inside the groovy macro and will fail
on the {{include}} part I think since it's not valid groovy syntax.
I agree
Now the groovy code could do something like out.println("{{include
document='...'/}}")
In this case the resulting macro will get executed (since the logic is
that the new rendering uses the MacroTransformation to execute the
macros and this transformation continues to execute till there's no
more macro to execute).
Now if the included document contains groovy code not inside a groovy
macro nothing will happen and the code will be printed as standard
text (no groovy execution). If it's inside a groovy macro then it'll
get executed but only once since the groovy macro in the page doing
the include will have already executed.
To summarize, I think the fact that outside macros execute before
nested macros prevents dangerous things to happen in general. Now I
haven't analysed all cases yet so if you see something dangerous
please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy?
To answer your question Pascal, you would write:
{{groovy}}
... some groovy code...
{{/groovy}}
{{include document="... page containing a groovy macro..."
context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first {{groovy}},
could you use it also in the {{include}} (if it basically contains also
{{groovy}} script) since you include the doc in current context?
I mean: are these 2 completely different groovy executions or do they share
the same execution context?
br
Pascal
Thanks
-Vincent
On Aug 5, 2008, at 9:36 AM, Pascal Voitot wrote:
Hello,
Do you foresee a special syntax for groovy scripts as you already
have for
velocity using {{velocity}} with some more features?
My idea is to be able to code cleanly using groovy and to put some
"generic"
part of scripts in separated documents and to be able to import them
in
other docs containing other parts of scripts.
It would be really nice to be able to type some part of scripts or
to define
some groovy classes in a page and tell "this is groovy code which is
not
"WIKI-renderable" as is".
Then we could simply import/include this script in another page
(just paste
the code without any rendering) using something like
#include("MySpace.MyGroovyDoc").
xwiki.parseGroovyXXX is useful sometimes but not when you only want to
include some part of scripts.
Existing #includeXXX macros always render the content and here I
only want
to paste a script from somewhere else
(xwiki.getDocument("").getContent() in
fact)
Moreover the idea would be also to allow using both
"xwiki.parseGroovy" and
the #include macro for the same groovy "document". For the time
being, one
need to use the trick
/* groovygroovy #* */
/* *# */
and then you are condemned to use xwiki.parseGroovyXXX because no
other
function can interprete this tricky syntax.
best regards
Pascal
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7 Aug
7 Aug
8:46 a.m.
On Aug 5, 2008, at 5:29 PM, Pascal Voitot wrote:
[snip]
It's exactly like now. If your groovy script is dangerous, whether
it's in one a standalone page or included in another page, it'll still
be as dangerous so you'll need to protect it. If the page is itself
protected the include will fail (not implemented yet in the new
rendering but planned). Thus you should either protect the page or use
an if to test for some rights.
One possibility we have would be to add an executionRights parameter
to the groovy macro in the new rendering that would default to
"programming" so that only users with programming rights would be able
to execute a groovy macro by default (to allow anyone you would add
executionRights="view"). Basically this would simply do the test for
rights on behalf of the programmer.
WDYT?
Yes they'll share the same context.
Thanks
-Vincent
To summarize,
I think the fact that outside macros execute before
nested macros prevents dangerous things to happen in general. Now I
haven't analysed all cases yet so if you see something dangerous
please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy? To answer your
question Pascal, you would write:
{{groovy}}
... some groovy code...
{{/groovy}}
{{include document="... page containing a groovy macro..."
context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first
{{groovy}},
could you use it also in the {{include}} (if it basically contains
also
{{groovy}} script) since you include the doc in current context?
I mean: are these 2 completely different groovy executions or do
they share
the same execution context?
3:59 p.m.
On Thu, Aug 7, 2008 at 8:46 AM, Vincent Massol <vincent(a)massol.net> wrote:
Yes they'll share the same context.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Aug 5, 2008, at 5:29 PM, Pascal Voitot wrote:
[snip]
It's exactly like now. If your groovy script is dangerous, whether
it's in one a standalone page or included in another page, it'll still
be as dangerous so you'll need to protect it. If the page is itself
protected the include will fail (not implemented yet in the new
rendering but planned). Thus you should either protect the page or use
an if to test for some rights.
One possibility we have would be to add an executionRights parameter
to the groovy macro in the new rendering that would default to
"programming" so that only users with programming rights would be able
to execute a groovy macro by default (to allow anyone you would add
executionRights="view"). Basically this would simply do the test for
rights on behalf of the programmer.
WDYT?
This is a philosophical question ;)
What do you prefer: let people control security completely or enforce some
basic security because people can't be expert immediately?
To my mind, ensuring some basic security controls is safer... And also
providing a mechanism to toggle it off knowing what you do...
So why not add this execution right control by default in the groovy macro
and provide an option allowing everyone to execute this groovy macro!
It would also prevent the groovy parsing and execution which is not bad for
performance and memory!
To
summarize, I think the fact that outside macros execute before
nested macros prevents dangerous things to happen in general. Now I
haven't analysed all cases yet so if you see something dangerous
please let me know so that I can fix it while it's possible.
So you think this might no be dangerous to use include for groovy? To answer
your question Pascal, you would write:
{{groovy}}
... some groovy code...
{{/groovy}}
{{include document="... page containing a groovy macro..."
context="current"/}}
Let me know if I missed something.
I have a question: if you create a groovy object in the first
{{groovy}},
could you use it also in the {{include}} (if it basically contains
also
{{groovy}} script) since you include the doc in current context?
I mean: are these 2 completely different groovy executions or do
they share
the same execution context?
5887
days inactive
5889
days old
15 comments
3 participants
participants (3)
-
Ludovic Dubost -
Pascal Voitot -
Vincent Massol