[pmwiki-devel] Rethinking ZAP permissions

[Rodney Morris]

I may be the person who asked that security question.  I've just
started fiddling with ZAP and I love the power it make available.

Rather than move away from AuthUser, I'd recommend bringing ZAP even
more inline with AuthUser's options.  Since AuthUser has been bundled
into the default install, there really won't be anyone who doesn't
have the same options available, at least.

The question I mentioned on your site (which may or may not have
spurred on this line of thinking) was whether ZAP could write directly
to a text file for storing logins and encrypted passwords.  I'm trying
to put my finger on exactly why, but the present method of storing
login information on wiki pages seems to lack the security of storing
it in a text file in a separate directory (particularly since the
password stored by ZAP isn't encrypted).  I was very happy when I
learned that AuthUser allowed alternative storage methods.

Now, I'll be the first to admit I'm a fairly novice user and am just
starting to learn how PHP and pmWiki works.  What I'm hoping for might
not even be possible.

To answer your questions more directly...

I definitely support removing those security functions where ZAP
overlaps with security functions available out of the box.  A single
ZAPAdmin security id should be enough.  Or just hardcode it... require
that people only be allowed to conduct the "plus" features when they
use the admin password.

Having different forms available to specific users would be
interesting, but even more powerful would be having different forms
available to specific user groups.  The page I'm currently designing
relies heavily on user groups (different people can access different
parts of the site), so this is definitely an interest of mine.

Having ZAP automatically create a "lock pattern" would be wonderful.
Or have a tutorial on your site with how to create your own, for
novices like myself who are just now learning how to use pmWiki and
php.

Thanks for the work you've been putting into this, Caveman.  I'm
really enjoying the possibilities ZAP makes available for pmWiki.

-Noctifer

On 11/16/06, The Editor <editor at fast.st> wrote:
> Someone just asked me a question about ZAP security that got me
> thinking of what may be a better system.  Thought I would post it to
> the list and see if anyone has any input.
>
> Currently zap divides it's functions by risk level into the following
> categories:
>
> SDV($ZAPauth[login], "read");
> SDV($ZAPauth[forms], "zap");
> SDV($ZAPauth[plus], "admin");
>
> "zap" is a custom permissions level that shows up in the page
> attributes page by default as id:*.  This allows you to have pages
> people can read and not zap or edit, or pages people can read and zap
> but not edit.  Probably what Pm will do for the upcoming commenting
> feature.
>
> Anyway, the thought occurred I could just require all zap features to
> use the zap permissions level, and then leave it with the web admin to
> set the desired level of protection for each form using page (or
> group) attributes.  It would be a bit more trouble perhaps, but more
> intuitive, and allow them more flexibility and control--without the
> need to modify config files.  It would also simplify the coding some.
> And it is more in line with how PmWiki works already.
>
> The disadvantage is that any form without a lock pattern could
> potentially be hacked (forged headers) giving that person access to
> all ZAP's commands (modules) avaiable on that page.  Admin's might be
> tempted to think that because a form only has simple features it
> should be available to any viewer, or any member--not realizing all of
> zap is potentially available to a skilled hacker.  (ZAP has never been
> hacked to my knowledge).  ZAP "lock patterns", of course, would
> continue to be available.  And the risk is somewhat mitigated by ZAP's
> new modular structure, which can enable riskier modules only in
> certain groups... But one of my design goals was to avoid having to
> edit multiple local config files wherever possible.  Maybe a
> ZAPallow[module] variable with a CSV list of groups/pages where that
> module can be checked?  That way everything could be set in one config
> file...
>
> Second, I'm thinking about removing the AuthId from the security
> session variable so ZAP works better with password based sites (not
> using AuthUser).  Doing both of these together adds some nice
> possibilities, like having different forms available to specific
> users, or those with specific passwords, or whatever.  Anyone have any
> thoughts?
>
> How about an even wilder idea:  what if ZAP could automatically create
> a "lock pattern" for each form?  Is there some way the (:zapform:)
> markup can access the text of the page it is on, retrieve all the
> input fields, parse the args and proceed from there?  Perhaps you
> could prepend a field value with some symbol ( ` ) to indicate that
> value is not changeable, and then strip it out in processing.  Any
> thoughts?
>
> Cheers,
> Caveman
>
> _______________________________________________
> pmwiki-devel mailing list
> pmwiki-devel at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-devel
>