[pmwiki-users] adding cookbook script
Patrick R. Michaud
pmichaud at pobox.com
Sun Feb 24 16:17:12 CST 2008
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
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
- 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
- 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.
More information about the pmwiki-users