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 _______________________________________________ pmwiki-users mailing list pmwiki-users@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-users
