In an attempt to use the docsearch plugin we realized that giving an id with a leading ":" can lead auth_aclcheck to give unwanted access to ressources.
The docsearch plugin replaces temporarly the savedir/indexdir pair to get search results from its own file tree, one of the side effects of this method (I have no idea why but I think that shouldn't matter) is that returned ids are prefixed with ":".
The problem is that auth_aclcheck checks this id against acls which do not have leading ":", and then ignores some acls !
Example :I have a "foo:bar:file.pdf" ressource (that is analysed by the docsearch plugin) that contains the word "stuff"
I have a page "foo:page" that contains the same word acls are like : * @ALL 1 foo:bar:* @ALL 0When I search the word "stuff" as guest I get the "foo:page" page, that is logical.
But I also get the foo:bar:file.pdf ! Why ? Because the docsearch plugin sets the datadir on {savedir}/docsearch/pages and then triggers fulltext search again, and for some reason the returned id is ":foo:bar:file.pdf" and not "foo:bar:file.pdf"
Then when the _ft_pageSearch function loops through founded docs it calls auth_quickaclcheck upon ":foo:bar:file.pdf", which calls auth_aclcheck, which looks for acl for ":foo:bar:file.pdf".
Because there is none it goes to the parent ns (with getNS function) which returns ":foo:bar", and checks for acl again.
The problem is that there is an acl but for "foo:bar" and not ":foo:bar" so it is skipped !
A simple workaround is to add a call to cleanID at the beginning of auth_aclcheck like :
$id = cleanID($id);
Another place to do this would be in the loop at the end of
_ft_pageSearch function in fulltext.php but the fix wouldn't be as generic.
This acl checking failure may lead to some big information leak, so I think this is more of a core problem than a plugin problem (btw the plugin is only using core features so I don't think its doing somthing wrong)
Etienne -- DokuWiki mailing list - more info at http://www.dokuwiki.org/mailinglist
