[pmwiki-users] PageVar security (was: How to detect if a page has @nopass for the read password)

Eemeli Aro eemeli at gmail.com
Tue Jul 13 16:55:20 CDT 2010

On 14 July 2010 00:20, Petko Yotov <5ko at 5ko.fr> wrote:
> On Tuesday 13 July 2010 13:41:27, Eemeli Aro wrote :
>> Which actually raises an interesting point: is it really sensible that
>> page variables don't obey any permissions, but are always accessible?
>> Page text variables are protected, mind. Would it really give a huge
>> performance hit if PageVar() also checked for permissions before
>> processing a page variable?
> Most default PageVariables have to be visible even if the page is read-
> protected, for example {$Author}, {$Group}, {$FullName}, {$DefaultGroup} etc.,
> otherwise major parts of PmWiki may break, notably links and skins. And
> because the PageVariables are 'eval'-uated from strings, we can't know in
> advance if a page should or shouldn't be checked against permissions. So we
> don't check. I don't think that is a problem that needs to be addressed at the
> moment.
> If admins add new PageVariables, they should know that these are potentially
> visible for all pages. We should document this. OTOH, a PV can be defined with
> a custom function which uses RetrieveAuthPage() to check permissions.
> Petko

Actually, none of that would break if the $page in PageVar() came from
RetrieveAuthPage() instead of ReadPage(). The only default entries in
$FmtPV that refer to $page are $Title, $Titlespaced, $Description and
$LastModified*, and of those the titles default to the page name
(which I agree shouldn't be protected).

The $PCache check would need to be complicated a bit, to something
similar to what's done in PageListProtect().

As for why I think this ought to be done, I at least find it
unexpected that I can read the given title, description and change
summary of any page even if I don't have read access to it. This
metadata about a page should get the same protection as the page


More information about the pmwiki-users mailing list