To be more precise, I am currently facing this issue when trying to implement http://jira.xwiki.org/browse/XWIKI-11416 and I need to remove the PR check in the wiki script service to be able to edit wiki descriptors in a subwiki, hopefully without unwanted security holes. Thanks, Eduard On Fri, Dec 12, 2014 at 4:47 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:

[Warning: this is just some incoherent Friday late evening thoughts with low information density ... well, now that I have written them down I will send the mail anyway. Executive summary: No, I did not have a good idea that solves the problem.] On 12/12/2014 03:47 PM, Eduard Moraru wrote: I have to admit that I did only thought about getting rid of PR checks in case of the "Activity Stream" use case, where the only need to have PR on the page is to skip read access restrictions in the HQL query. In such a case where it is only about proper reading data and only showing the user the data he/she has the right to see the "add an API script service and check things there" is possible, because the worst thing a malicious user can do is adding 1000 Activity-stream macros to the page and then have a very slow page ... However when it comes to an API where users can write things, then these checks are clearly not enough to prevent malicious users writing scripts that could be involuntarily triggered by sufficiently powerful users. I cannot even see how the user could be informed property that the action is really the one that this user wants to perform (i.e. the script might be really save the wiki description, but not from the values the user has typed in, but some garbage the script author has pulled, and it only does so on Friday 13th.) In case of XWIKI-11416 (wiki description admin) I vaguely thing that these pages should only be editable and visible to admins, (which is something that the Script-API might be able to check), and that might be an idea: do not require programming rights from the document author, but only the Admin rights that the user performing the actual action requires too - if the author is an Admin, too, he/she could have just gone ahead and make the change instead of building traps for the colleagues. However I feel that I am overlooking something here ... Aside of that I guess as one can not really limit what the script author is allowed to without making the scripting capability useless. Basically you have to trust the script author ... I first thought about something like checking on document save that the script contents have not been modified, and if that is the case, keep PR rights to the page, but then I figured out that all what I was trying is to reinvent a poor "signed scripts" solution :) Part of the problem in XWIKI-10446 is actually that the wiki pages belong to the user who has installed them, even thought the contents come from some archive, and it would be better if the pages belong to some "trusted installer" (maybe "superadmin", if only that one already exists), allowing local admins in subwikis to install extensions without having the need for PR themselves. But I guess that idea has already been dismissed? After all this does not handle the use case where an UI with pages requiring PR are installed, ant the local admin just wants to rename some button label. However at least they could install extensions ... Cheers, clemens