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

[Eemeli Aro]

On 14 July 2010 00:20, Petko Yotov <5...@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
itself.

eemeli

_______________________________________________
pmwiki-users mailing list
pmwiki...@pmichaud.com
http://www.pmichaud.com/mailman/listinfo/pmwiki-users

[Petko Yotov]

On Tuesday 13 July 2010 23:55:20, Eemeli Aro wrote :
> On 14 July 2010 00:20, Petko Yotov <5...@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.
> >

> 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
> itself.

I think that you're right -- we should try to change this, while allowing
admins to revert back to the ReadPage() function if it is important to them.

ToDo.

Thanks,
Petko