Hi Rob,
I'm not sure I agree that they cannot work. What they cannot do is be supported between versions, and it will be hard to prove robustness. If you patch one version completely, a new one with new holes will soon appear - special pages etc.
http://conseil-recherche-innovation.net/index.php/1974/04/11/41-restrict-pag...
This lot have done an admirable job of trying to keep up with the MW codeline, but the base codeline seems resistant to the hooks they require to maintain it. Instead they patch diligently each version a few weeks later. Whether this actually patches every possible hole is probably mute. After all early MW versions had XSS vulernabilities (and probably still do as new ones are found).
Security is a piece of continuous work, not something that can be done and forgotten about. It is also requires the collaborative approach - by people that understand the code and implications of doing certain things. MW authentication has come on leaps and bounds due to parser hooks, though much is not used by MW itself. It would be nice to see a similar approach adopted for permission hooks. People could report holes, and they could get hooks put in it the relevant places.
The MW code does not have too many points where pages can be obtained from the database. Looking thru the patch main area is in the searches and title listing. Unifying and hooking those would go a long way towards creating a robust way to produce an access control extension that was robust for the core and for special pages.
As for document management systems, well I think you can be quite smug in the knowledge that your solution is several times better than any commerical products for knowledge gathering and desimination.
So I second the call for more hooks - at least enough so that the chaps doing the view restrict patch don't have to fight every release of MW. I also fully accept its not in the direct path of MediaWiki at the moment - but then the wikipedia used to be completely open and editable by anyone ;).
Regardless, keep up the good work. I'm sure that time will resolve this problem in some fashion...
Best wishes
Alex
---------- Forwarded message ---------- From: "Rob Church" robchur@gmail.com To: "MediaWiki announcements and site admin list" <mediawiki-l@wikimedia.org
Date: Sat, 8 Jul 2006 12:02:48 +0100 Subject: Re: [Mediawiki-l] Permission to only access certain articles for users? On 08/07/06, Gregory Szorc gregory.szorc@gmail.com wrote:
If only the UserCan hook was called more and more. I would love a global variable like $wgInsanePermissions that, when activated, would have
Article
and Title constructors, etc call UserCan for ($wgUser).
It wouldn't help, though, because MediaWiki is built around being able to access the content via hundreds of different methods...hence the reason all these hacks don't work 100%.
Rob Church
I'm not sure I agree that they cannot work. What they cannot do is be supported between versions, and it will be hard to prove robustness. If you patch one version completely, a new one with new holes will soon appear - special pages etc.
http://conseil-recherche-innovation.net/index.php/1974/04/11/41-restrict-pag... So I second the call for more hooks - at least enough so that the chaps doing the view restrict patch don't have to fight every release of MW. I also fully accept its not in the direct path of MediaWiki at the moment - but then the wikipedia used to be completely open and editable by anyone ;).
As the author of the patch, I agree this point of view! I do not do lobbying for the same reason (its not in the direct path of MediaWiki at the moment). But as the time pasts, we see the need to control some actions (eg. creation of new pages for unregistred users). So IMO, the ACL model should be generalised in the core of MW.
It wouldn't help, though, because MediaWiki is built around being able to access the content via hundreds of different methods...hence the reason all these hacks don't work 100%. Rob Church
I think the patch works at 100% concerning page content accesses (except in case of MW security hole of course). For titles, as you say there are many ways to retrieve them. But the patch seems quite secure concerning titles retrieving as well. The problem is more that it's not a beautiful way to build a proved security model...
Jej
mediawiki-l@lists.wikimedia.org