[pmwiki-users] AuthUser

[Peter Bowers]

On Tue, May 3, 2011 at 7:35 PM, Sandy <sandy at onebit.ca> wrote:
> Is this confirmed, both that one way has the hole and the other doesn't?

Yes, definitely there is a hole if you set all your security using
conditionals in your config.php

> Near as I can tell, you're setting the same parameters either way, so I'd
> expect the results to be the same.

No, the idea was inherently flawed.

Let's say I have user1 that I want to have access to group1 but not to
group2.  Similarly I have user2 that can read group2 but not group1.

If I put those permissions on the Group1.GroupAttributes?action=attr
and Group2.GroupAttributes?action=attr then regardless of who I am
pmwiki will appropriately read the appropriate attributes and
allow/deny appropriately.

However, if I put this in my config.php:

if ($group=='Group1')
   $DefaultPasswords['read'] = 'id:user1';
elseif ($group=='Group2')
   $DefaultPasswords['read'] = 'id:user2';

And then I come into Group1.Page1 as user1 I have default read
privilege by DEFAULT.  It's not that I have set one default for one
group and another for another group.  I have one default for my whole
system.  That default changes depending on which primary page I'm
trying to access (Group1.Page1 vs Group2.Page1), but once it's set it
is set for the whole site (unless overridden by a particular page).

So if I, as malicious user1, want to see what is in Group2.Secrets all
I have to do is edit Group1.Page1 and (:include Group2.Secrets:).  Now
when I view that page (Group1.Page1) my default passwords become
id:user1 and so by default I can read Group2.Secrets even though my
(faulty) logic was trying to prevent that.

> Or are there other things that should be done when changing those variables?
> If so, is there a function that can be called from config.php that will do
> all the housekeeping?

There would have to be some way of setting per-page and per-group
authorization via PHP.  Theoretically this could be done by messing
around with page cache and stuff, but you *really* don't want to go
there unless someone has a gun to your head... :-)  Or someone could
write some kind of additional wrapper around authuser that would check
some other data structure, but this is definitely talking about coding
up a new recipe, not just a quick config job...

> If it is possible to see and (:include:) file which you don't have access
> to, and access was set properly, then it's a bug.

The key is "and access was set properly."  If you have set the access
properly by editing the ?action=attr then you are golden -- even my
bad configuration methodology will not give anybody privileges that
contradict those you have set in that manner.  But if you had followed
my (faulty) instructions to set *all* your privileges (doing it all in
config.php and not using ?action=attr) and thought that access was set
properly by that manner then authorization would have been
compromised.

This is not a bug at all.  This is just GIGO and I played the role of
the garbage producer... :-)

-Peter