Details
-
Type:
Improvement
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.3 RC1
-
Fix Version/s: None
-
Component/s: Old Core
-
Labels:None
-
Similar issues:
XWIKI-1137Global access levels are displayed in the local rights editor XWIKI-8131Security authorization component should log denied access for simple right inquiry at debug level XWIKI-2417Add access level query functions for the GWT API XWIKI-2430Unable to add "List of groups" and "Access Right levels" properties to class XWIKI-194Access control lists at group and space level seems to work intermittently XWIKI-58 Rights at the class or property level XWIKI-2183 Configurable Access Rights granularity XWIKI-8954Programming right should imply Admin right and not the reverse (new security module) XWIKI-7149Forbidding delete right transforms undelete right in "un" right
Description
We should add a new access level, "rights", which controls who can edit the access rights.
Currently, this is controlled by the "edit" right, but it means that a user who can just view and edit a page can give himself other rights, like delete or comment (fortunately it is not possible to grant higher rights on a page).
I had overlooked this problem. A "rights" access level would be nice. But also a second, more privileged "super rights" access level to assign "remove", "programming, and "admin" rights.
But for this should work in practice, the rights must be stored outside of the ordinary document content.
I have temporarily worked around this by removing the delete access level from being applicable at page level in my right service implementation. (Creator still gets delete access by default.) But also, one must make sure that "WebPreferences" exists in all spaces and set deny on the edit right for XWikiAllGroup on this page.