On Tue, May 3, 2011 at 7:35 PM, Sandy <[email protected]> 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 _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
