-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
MinuteElectron wrote:
A few months ago in r29725 http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=29725 Domas introduced a "shortcut" that bypassed the userCan hook when $wgGroupPermissions['*']['read'] = true; as a performance enhancement. This circumvented any further logic inside the userCan hook that may apply read restriction so I reverted it (it had broke an extension -- and possibly others, made the behavior of the hook unintuitive, wasn't documented, etc.). Apparently (according to Domas) he had asked both Tim and Brion about it and they agreed upon it, so he reverted it back.
The order of permissions configurations in MediaWiki's security model goes from 'deny' to 'allow'.
That is, a general setting of 'allow' will shortcut anything else, because the blanket permission will always apply.
A general setting 'deny' means that further, finer-grained checks can be done to see if another group or per-user permission will activate the 'allow'.
Now, if LockDown is following that model -- denying all access by default, then allowing access conditionally -- then as far as I know it should work just fine. This means that you need to set the default restrictions correctly in $wgGroupPermissions.
If it's not -- say by allowing all access by default, then trying to deny it conditionally -- then indeed it will break. By not following MediaWiki's security model, you end up with unexpected behavior. If this is the case, then LockDown should be fixed to follow MediaWiki's permission model correctly.
- -- brion vibber (brion @ wikimedia.org)