Refactor permissions, ACLs, capabilities

Moin has ACLs - currently just for page access control.

It also has some non-ACL settings for controlling permissions.

Non-page non-ACL permissions

• superuser setting, used for:
  • Despam action (only available to superusers)

  • SystemAdmin macro (only available to superusers)

  • SystemInfo macro (superuser gets all infos, everyone else does not get much infos)

  • WikiConfig macro (only available to superusers)

  • "user_created" event - superusers can be notified
  • suid feature

  • AttachFile - install package

  • userprofile action
  • thread_monitor action
• backup_users - who may do a wiki backup
  • used by backup action
• textchas_disabled_group - who does not need to answer questions
  • used by security.textcha (page editor, user creation)
• allow_xslt - globally allow/disallow xslt
  • text_xslt parser
• openid_server_enable_user and openid_server_restricted_users_group
  • Page, action serveopenid, userprefs oidserv
• actions_excluded - which actions are globally disallowed
  • used by theme for not showing what's not allowed
  • used by action dispatcher

It would be nice to refactor all this to use ACLs, to have better control and less settings.

Plan

superuser setting

Currently, superuser is just a list of names and u.isSuperUser() checks for membership in that list.

As a first easy step, superuser setting could be removed and replaced by a 'super' capability in a global ACL.

old: superuser = [u'JoeDoe', u'JaneDoe', ]

new: acl_rights_foo = u'JoeDoe,JaneDoe:super'

Later, 'super' could be replaced by more fine grained capabilities.

TODO: how do we call that ACL?

backup_users

See section about 'superuser', capability 'backup'.

textchas_disabled_group

See section about 'superuser', capability 'notextcha'.

allow_xslt

XSLT rendering (like raw, unsafe HTML rendering) allowance maybe should be done on a per-page basis.

If you have some pages that are read-only for untrusted users, it can be fine to have html/xslt enabled on them.

OTOH, you don't want xslt/html rendering on pages that are editable by untrusted users.

Capability 'unsafe' could enable raw html / xslt and other unsafe content rendering.

actions_excluded

Unclear how to handle this best.

We maybe don't want to have 1 capability per action.

So just keep it as it is?

vague idea about acls for actions

• read, write, etc. could be the generic capability (used by everything)

• read.info could mean a specific capability, "read when done by info action"

  • info action would

    • first check read.info and use that, if present

    • otherwise it would check read and use that

• every action should deniable by acl. e.g. #acl SomeUser:-info,-diff

  • by given dependencies in the action modul, denying read would also deny dependent actions e.g. info, raw, print etc.

See also FeatureRequests/AclExtendedToMakePluginsSecure.

CategoryFeatureRequest