[pmwiki-users] adding cookbook script

[Patrick R. Michaud]

On Sun, Feb 24, 2008 at 11:52:05AM -0500, DaveG wrote:
> 
> 
> Patrick R. Michaud wrote:
> >A similar argument goes for storing parts of config.php into
> >a wiki page -- it means that someone who is able to modify
> >those pages somehow can start executing arbitrary scripts
> >on the server.  There may be cases where this would be
> >okay, but in the general case I think it's too big a
> >security risk for the core.
>
> I understand the sentiment behind this, but almost every other web 
> blog/wiki platform out there provides some kind of admin pages for 
> installation or at least configuration of themes and plugins.
> 
> At some point we need to balance ease-of-use vs security we provide. 
> Note, I'm not saying security isn't important. I'm suggesting we 
> consider alternate ways of moving the pointer towards usability, without 
> significantly compromising the security of the platform.

In previous postings I've outlined the things that I think might
be do-able for a web-based configuration tool and the things that
aren't.  While I think a web-based configuration tool might be
able to help with basic setting of certain configuration variables,
I think having it be able to automatically install recipes,
skins, or upgrades isn't very likely, given the inherent security
risks.

That said, there's really no reason why someone can't prototype
a recipe for this, as a "proof of concept" if nothing else.  
(Hint:  If people are waiting for *me* to do it, it's not likely to 
happen anytime soon unless there's an absolutely HUGE outcry for it.)

I can give some outlines of what such a recipe might look like:

- The simplest approach would be to have a web form that allows
  an admin to directly enter PHP settings, instead of having
  to edit local/config.php .  But this is really insecure,
  because it means anyone else able to write files on the server
  can start running arbitrary scripts and commands.

- Thus, because allowing direct PHP is dangerous, the better approach
  is to have some sort of form that limits the things that can be
  set.  But defining the list of what can be set or not set is a
  challenge.  In some sense it also presumes that most settings
  are simple variable settings, without any if/then or other
  conditional logic in place.  In my experience that's not the
  case.

- The configuration files are somewhat sensitive to the order in
  which things happen -- some scripts have to be loaded early,
  some late, some variables set early, others late, etc.  So, any
  sort of configuration utility has to be smart enough to know
  the order in which certain settings are to take place.

- If the configuration system is menu/field based, then there
  needs to be a way for recipes to easily indicate what options 
  they provide.

- Given the incredibly huge number of configuration possibilities
  for PmWiki, the admin interface needs to be well organized into
  separate subsections.  In other words, I don't think it's workable
  to provide all configuration options on a single page.

Those are a few thoughts, if anyone wants to give this a go.

Pm