[xwiki-devs] [proposal] Add xcontext.dropPermissions() function to take away all programming/script author permissions when called.
I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api. The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor) Once permissions have been dropped, they cannot be regained (for the duration of the request.) This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username. Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution. WDYT? Caleb
+1 in general, but in order to *really* drop permissions all methods checking PR should return false (i.e. also in XWikiRightServiceImpl), privileged methods called from Java directly should fail, groovy should stop executing etc. Dropping rights in Api is a good start though. Thanks, Alex On 09/13/2010 12:21 PM, Caleb James DeLisle wrote:
I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api.
The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor)
Once permissions have been dropped, they cannot be regained (for the duration of the request.)
This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username.
Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Alex Busenius wrote:
+1 in general, but in order to *really* drop permissions all methods checking PR should return false (i.e. also in XWikiRightServiceImpl), privileged methods called from Java directly should fail, groovy should stop executing etc.
That's a good point and a security manager will help because the next call to checkPermission will throw an Exception. Groovy would not stop executing until it did something which caused the security manager to be checked (eg: reflection).
Dropping rights in Api is a good start though.
Thanks, Alex
On 09/13/2010 12:21 PM, Caleb James DeLisle wrote:
I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api.
The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor)
Once permissions have been dropped, they cannot be regained (for the duration of the request.)
This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username.
Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+0 On Mon, Sep 13, 2010 at 12:21, Caleb James DeLisle <[email protected]> wrote:
I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api.
The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor)
Once permissions have been dropped, they cannot be regained (for the duration of the request.)
This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username.
Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
done in r31150 for http://jira.xwiki.org/jira/browse/XWIKI-5503 Caleb Thomas Mortagne wrote:
+0
On Mon, Sep 13, 2010 at 12:21, Caleb James DeLisle <[email protected]> wrote:
I think this function would be useful, I have used code like it to make sure scripts didn't run with PR when they shouldn't and I think it deserves a place in the api.
The function doesn't need any special privileges to run, but after it's run, api.Api#hasProgrammingRights will always return false and api.Document#saveAsAuthor will be attempting to save as the guest instead of the real document author. (likewise with getDocumentAsAuthor and deleteAsAuthor)
Once permissions have been dropped, they cannot be regained (for the duration of the request.)
This depends on another function in api.Api which is package private. String getEffectiveScriptAuthorName() returns the name given by XWikiContext.getDoc().getAuthor() unless dropPermissions() has allready been called or XWikiContext.getDoc() == null in which case it returns the guest username.
Why in the old api.Context? I envision in the future a SecurityManager component will exist which distrusts not only script but core java as well. I think the option to drop privileges when unneeded should also be present in the final security manager implementation. Since security managers require a large secure code base to be useful, I am proposing api.Context#dropPermissions() as an interim solution.
WDYT?
Caleb
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Alex Busenius -
Caleb James DeLisle -
Thomas Mortagne