[pmwiki-users] Protection of attachments!?!

Patrick R. Michaud pmichaud at pobox.com
Wed Nov 30 12:13:06 CST 2005


On Wed, Nov 30, 2005 at 07:07:19PM +0100, Mikael Nilsson wrote:
> > From time-to-time we've also discussed having an "installation analysis"
> > script that would review the current settings and environment and point
> > out things that might be overlooked.
> 
> Can that really be done? Well, maybe. I think a simple checklist is
> actually much more useful, as the admin gets to learn a few things at
> the same time...

The installation analysis can be checklisted as well -- it identifies
in its output everything that it checks and a status result of
"ok" or "not ok".

> > The default settings are as follows:
> >    The default admin password is locked.
> >    Main.GroupAttributes locks the attr password for pages in the Main group.
> >    PmWiki.GroupAttributes locks the attr password for pages in the PmWiki group.
> >    Site.GroupAttributes locks editing for pages in the Site group.
> >    By popular demand, Site.SideBar is unlocked for editing.
> 
> Is this documented?

Yes, in PmWiki.PasswordsAdmin:

    By default, PmWiki has the following password settings:
    * The admin and upload passwords are locked by default.
    * The Main and PmWiki groups have a locked attr password 
      (in their respective GroupAttributes pages).
    * The pages in the Site group except Site.SideBar are 
      locked against editing. 

However, after thinking about this a bit more I think we may be
able to reasonably eliminate the default password settings on
the Main and PmWiki groups.  Those were in place to prevent people
from editing and then password protecting various system-related
pages such as PmWiki.EditQuickReference and Main.SearchWiki.  Since
those pages have now moved into the Site group, I don't know that
we need protections on Main and PmWiki anymore.

> > > At the very least, it should be documented very clearly what steps are
> > > needed to lock down an installation:
> > > * Provide passwords etc. in config.php
> > > * Check all GroupAttribute pages so that they do not 
> > >   improperly override this (They do out of the box).
> > 
> > Unfortunately there's not widespread agreement about what constitutes
> > "improperly override".
> 
> Sorry, that only was referring to "improperly as viewed by the admin",
> not worldwide :-).

I'll rephrase:  Unfortunately, not all admins agree as to what is
a "proper" versus an "improper" override.

Pm




More information about the pmwiki-users mailing list