[xwiki-devs] [proposal] Add xcontext.dropPermissions() function to take away all programming/script author permissions when called.
13 Sep
2010
13 Sep
'10
12:21 p.m.
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
14 Sep
14 Sep
11:37 a.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:26 p.m.
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
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
16 Sep
16 Sep
10:42 a.m.
+0
On Mon, Sep 13, 2010 at 12:21, Caleb James DeLisle
<calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4:47 p.m.
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
<calebdelisle(a)lavabit.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5167
days inactive
5170
days old
4 comments
3 participants
participants (3)
-
Alex Busenius -
Caleb James DeLisle -
Thomas Mortagne