Table of Contents IntraACL extension for MediaWiki REQUIREMENTS INSTALLATION PERMISSION MODEL WARNING 1 WARNING 2 SemanticMediaWiki MediaWiki 4 Intranet

IntraACL extension for MediaWiki

IntraACL extension for MediaWiki is the page rights extension loosely based on HaloACL, correcting its endless bugs and inconveniences.

• Homepage and help: http://wiki.4intra.net/IntraACL
• License: GNU GPLv3
• Copyright (c) 2010+, Vitaliy Filippov, Stas Fomin
• Loosely based on HaloACL (c) 2009, ontoprise GmbH
• This is IntraACL backed by the new storage code.
• Version number is 2.2.0-dev.

REQUIREMENTS

• MediaWiki 1.19-1.26 (and also maybe later versions)
• PHP >= 5.3
• MySQL/MariaDB >= 5.1 or PostgreSQL >= 9.0

INSTALLATION

• Add the following lines into your LocalSettings.php:

  require_once('extensions/IntraACL/includes/HACL_Initialize.php');
  enableIntraACL();

• You can also add custom configuration options before enableIntraACL() call. For the option list, see extensions/IntraACL/includes/HACL_Initialize.php or http://wiki.4intra.net/IntraACL
• Apply patches for appropriate version of MediaWiki:

  cd YOUR_WIKI_INSTALLATION_DIR
  patch -p1 < extensions/IntraACL/patches/IntraACL-MediaWiki-<YOUR_VERSION>.diff

• Run MediaWiki database update tool:

  php maintenance/update.php

The method of IntraACL installation via the super-duper-installer of Halo MediaWiki bundle is now removed as very non-standard.

PERMISSION MODEL

IntraACL is for page-level permissions.

Permissions are defined in ACLs. ACLs are wikipages in ACL namespace and may be defined for:

1. Pages (ACL:Page/)
2. Page trees (page + subpages) (ACL:Tree/)
3. Categories (ACL:Category/)
4. Namespaces (ACL:Namespace/Main, ACL:Namespace/)

Each of these is considered a "level of ACL specificity". Coexisting ACLs of different "levels" are combined according to $haclgCombineMode which may be EXTEND, OVERRIDE or SHRINK:

• if EXTEND, the permission is granted if it's granted at ANY level

  thus a permission granted for the whole namespace can't be revoked at page or category level

• if OVERRIDE, the permission is granted only if it is granted at MOST SPECIFIC level

  i.e. page ACL overrides tree ACL, tree ACL overrides category ACL, category ACL overrides namespace ACL

• if SHRINK, the permission is granted only if it is granted in coexisting ACLs of ALL levels

If there are ACLs for multiple categories and/or parent categories of the same page, they always "extend" each other.

There are permissions for CREATE, READ, EDIT, DELETE, MOVE, MANAGE and PROTECT_PAGES actions. First 5 are obvious, MANAGE and PROTECT_PAGES are for ACLs (see below).

Also there is $haclgOpenWikiAccess setting which means "allow everything that's not denied explicitly" when it's true (OpenWikiAccess) and "deny everything that's not allowed explicitly" when it's false (ClosedWikiAccess).

Permissions for ACL pages:

1. anonymous users cannot read and modify any ACLs
2. ACLs for non-existing [incorrect] protection elements are accessible by everyone in OpenWikiAccess and by no one (i.e only by admins) in ClosedWikiAccess
3. ACL can be read by everyone who can read the protection element (page, namespace, or category)
4. existing ACLs can be modified or deleted by:
   1. users granted with MANAGE action in ACL itself
   2. for page ACLs: also by users granted with ACTION_PROTECT_PAGES in page namespace or category ACL
5. page, page tree, special page and category ACLs can be created by:
   1. if there is a namespace ACL or parent category ACL for this page/category:

      by users granted with PROTECT_PAGES action in any of these ACLs

   2. otherwise:

      by everyone in OpenWikiAccess and by no one in ClosedWikiAccess

6. namespace ACLs can be created only by admins
7. groups and right templates can be created by everyone

WARNING 1

This is not an ideal scheme due to the fact that categories are set inside page content. This means everyone who can edit a page may modify its permissions - at least by removing categories, or by adding his own category granting additional permissions to him. This is important especially in conjunction with PROTECT_PAGES permission. Consider the following example:

1. user A can edit article X, can create categories and category ACLs
2. he created Category:HisOwnCategory and ACL:Category/HisOwnCategory granting PROTECT_PAGES to him
3. he adds marker to article X
4. he gets the right to change ACL:Page/X
5. he creates ACL:Page/X and thus "takes over" the article. No one more can see the article but him :-)

You should consider this when defining permissions for your wikis.

WARNING 2

ANY installed extension MAY lead to SECURITY BREACHES.

This is because of MediaWiki by-design openness and extensibility and the need for direct database queries from extension code.

You should check that all your extensions perform access right checks using $title->userCan('read') before displaying $title content.

When showing page listings from the DB, you can use a stored procedure for permission checks using the FilterPageQuery hook to modify your query (for details see FilterPageQuery in includes/Evaluator.php)

SemanticMediaWiki

The original feature of HaloACL (protection of semantic properties via encrypting them) is also removed. IntraACL is thus incompatible with the original SemanticMediaWiki.

You may however try the version from Mediawiki4Intranet: https://github.com/mediawiki4intranet/SemanticMediaWiki - it is slightly outdated (only 1.8), but it contains a patch which enables read permission checks in every place that displays information.

If you have experience in PHP you may also try to rebase that patch for newer SMW versions and send it to us :)

MediaWiki 4 Intranet

You can also use Mediawiki4Intranet bundle. It already includes IntraACL and many other useful extensions which are patched to perform access right checks.

See http://wiki.4intra.net/Mediawiki4Intranet