-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

okparanoid wrote:

Don't understand why this was reverted without any explanation and consensus finding...

isn't Usercan an official hook of mediawiki ?

Doing this is simply bypass this documented hook !?

Don't know how duesentrieb can rewrite extension since the hook is

bypassed.

Perhaps i have missing something...

The full story.

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.

There isn't much more that can be done, maybe Brion will make a definitive decision next time he is here -- but this is a major regression so one would hope it is fixed somehow.

MinuteElectron.

MinuteElectron wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

okparanoid wrote:

...

Don't understand why this was reverted without any explanation and consensus finding...

isn't Usercan an official hook of mediawiki ?

Doing this is simply bypass this documented hook !?

Don't know how duesentrieb can rewrite extension since the hook is

bypassed.

...

Perhaps i have missing something...

The full story.

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.

There isn't much more that can be done, maybe Brion will make a definitive decision next time he is here -- but this is a major regression so one would hope it is fixed somehow.

MinuteElectron.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkflm/sACgkQkJvUlhoE3wTDOgCfX/s8qmO5zFen0yCqPrNxz486 rxUAnj3LmrCPh/NhGx0n1h+GJwDWw6QG =efoJ -----END PGP SIGNATURE-----

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

So is it possible to add an condition to the line ?

if ($wgGroupPermissions['*']['read']) && "usercan hook not activated"

perhaps any boolean can store if the hook is to be activated, why not set this boolean in LocalSettings.php and use it to any other place of the code to not penalize perfomance of wiki which dont use the user can hook ???!

MinuteElectron wrote:

The full story.

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.

There isn't much more that can be done, maybe Brion will make a definitive decision next time he is here -- but this is a major regression so one would hope it is fixed somehow.

MinuteElectron.

Is calling wfRunHooks that expenseive? It returns almost immediately if no hooks are registered as "userCan"; and Title::userCanRead returns anyway after the hook if the user is allowed to read. I can't see why is the quick "shortcut" necessary, when many other hooks get called during every request.

Hi!

I moved the shortcut below the hook execution in r32354. If a hook is running too slowly, it should be fixed, not the call to wfRunHooks.

Well, the major issue then is to check for 'read' condition in any extension that uses userCan hook, and do fast execution without unstubbing too many objects.

but check $wgGroupPermissions. Domas, could you explain? Or someone?

and unstubs the User object, which can be skipped in quite many code executions :)

Hi!

Are "public wiki " using such extensions ?

maybe. we used to have some, that used - got nuked, then fixed :) I can't tell for every wikis out there - needs review of all extension hook usages.

BR,

Hello,

Is calling wfRunHooks that expenseive? It returns almost immediately if no hooks are registered as "userCan"; and Title::userCanRead returns anyway after the hook if the user is allowed to read. I can't see why is the quick "shortcut" necessary, when many other hooks get called during every request.

well, if hook exists, $wgUser object is unstubbed - and thats already expensive. there is no need of having stub handlers, if we start unstubbing everything at the beginning of every code path.

Brion Vibber wrote:

-----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)

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfn3q8ACgkQwRnhpk1wk44wAACgjtkEiJSUGbzLgN16W1tap9J0 ExQAoJd5/HsrQek+sswGfW6yvIFqsPB+ =65tc -----END PGP SIGNATURE-----

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

ok

It makes senses.

Thanks for you and daumas for explanation.

Regards

okparanoid wrote:

Hello

I have tried to correct Lockdown to being compatible with this model. I haved to let Lockdown grant access of specific group, which change a little the initial "philosophy" of the extension. To work with 1.12 $wgGroupPermissions['*']['read'] need to be set to false in LocalSettings.php

I'm not a php developper (don't know the language and don't know the api of mediawiki) so this has to be tested and certainly contains mistake. Don't use this in production !!! Please take a look at this and let me know the issues/mistakes.

Regards

P.S : Someone can contact the inital author of Lockdown, Daniel Kinzler alias Duesentrieb, i dont have found his email. I would like to propose him the patch.

---

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Here is the script can't attach file with the mailing list :

<?php

/** * Lockdown extension - implements restrictions on individual namespaces and special pages. * * @package MediaWiki * @subpackage Extensions * @author Daniel Kinzler, brightbyte.de * @copyright © 2007 Daniel Kinzler * @licence GNU General Public Licence 2.0 or later */

/* * WARNING: you can use this extension to deny read access to some namespaces. Keep in mind that this * may be circumvented in several ways. This extension doesn't try to * plug such holes. Also note that pages that are not readable will still be shown in listings, * such as the search page, categories, etc. * * Known ways to access "hidden" pages: * - transcluding as template (can't really be fixed without disabling inclusion for specific namespaces; * that could be done by adding a hook to Parser::fetchTemplate) * - Special:export (easily fixed using $wgSpecialPageLockdown) * - the search page may show excerpts from hidden pages. * - supplying oldid=<revisionfromhiddenpage> may work in somve versions of mediawiki. Same with diff, etc. * * NOTE: you cannot GRANT access to things forbidden by $wgGroupPermissions. You can only DENY access * granted there. */

if( !defined( 'MEDIAWIKI' ) ) { echo( "This file is an extension to the MediaWiki software and cannot be used standalone.\n" ); die( 1 ); }

$wgExtensionCredits['other'][] = array( 'name' => 'Lockdown', 'author' => 'Daniel Kinzler', 'url' => 'http://mediawiki.org/wiki/Extension:Lockdown', 'description' => 'per-namespace group permissions', );

$wgNamespacePermissionLockdown = array(); $wgSpecialPageLockdown = array();

$wgHooks['userCan'][] = 'lockdownUserCan';

function lockdownUserCan($title, $user, $action, &$result) { global $wgNamespacePermissionLockdown, $wgSpecialPageLockdown, $wgWhitelistRead; #print "<br />nsAccessUserCan(".$title->getPrefixedDBkey().", ".$user->getName().", $action)<br />\n";

$result = NULL;

//don't impose extra restrictions on UI pages if ($title->isCssJsSubpage()) return true;

if ($action == 'read' && $wgWhitelistRead) { //don't impose read restrictions on whitelisted pages if (in_array($title->getPrefixedText(), $wgWhitelistRead)) { return true; } }

$groups = NULL; $ns = $title->getNamespace(); if( NS_SPECIAL == $ns ) { if ($action != 'read') { $result = false; return true; } else { foreach ($wgSpecialPageLockdown as $page => $g) { if (!$title->isSpecial($page)) continue; $groups = $g; break; } } }

if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown['*'][$action]; if (!$groups) $groups = @$wgNamespacePermissionLockdown[$ns]['*'];

#this namespace has not specific configuration #continue processing without taking any decision if (!$groups) return true;

#print "<br />nsAccessUserCan(".$title->getPrefixedDBkey().", ".$user->getName().", $action)<br />\n"; #print_r($groups);

$ugroups = $user->getEffectiveGroups(); #print_r($ugroups);

$match = array_intersect($ugroups, $groups); #print_r($match);

if ($match) { #group is specifically allowed by lockdown - stop processing $result = true; return false; } else { #print "<br />DENY<br />\n"; #user is not member of a group specially restriced via lockdown #deny access and abort processing $result = false; return false; } }