Re: [Phpwiki-talk] index.php vs config.php

[Joby W. <joby@u.washington.edu>]

Jeff Dairiki wrote:
>>First it would be in PHP, I hate writing Perl.
> My current first choice would be python :-)

Python is pretty cool, but I am a language bigot.  I prefer C-like 
syntax languages.

> 
> More seriously, many people may not have the CGI/standalone version of
> PHP installed (properly) which makes running standalone PHP scripts
> a bit problematic.   The standalone PHP does not seem to be available
> in the RedHat 7.1 distribution, for example (though it is included
> in the 7.2 RPMs --- dunno about 7.3.)
>  

Oh I agree that not all would use it, but if we can provide 
configuration application independance by having settings be determined 
by the default config settings file (config-dist.php), then maintaining 
different configuration applications is trivial.  Although devising the 
commented code and parsing it seems non-trivial.

> 
>>My main motivation is to avoid exposing my database settings over the 
>>web.  Do you want it potentially available on the web that your data is 
>>in a MySQL database named 'phpwiki' on host 'sql.example.com' and logs 
>>into that database as 'wikiuser' with the password of 'securepasswd'?
> 
> 
> I see your point.
> 
> Perhaps the configurator script could be made so that it doesn't
> reveal the current values of sensitive settings --- it would still,
> of course, give you the option to change the setting to something else.
> You'd see something like:
> 
>   MySQL database name: <has been set, not shown for security reasons>
>             Change to: _______________________
> 
> (Or if a database name hasn't yet been set)
> 
>   MySQL database name: _________________________
> 

This would only work because the configurator exports the 
config-user.php file to be used.  If the file it exports has the current 
settings (assuming no changes) then we have the same problem.  If it 
doesn't include the settings then the end user will have to: 1) add the 
info each time, 2) manually merge the current (old) with the exported 
(new), 3) we would have to provide a tool to merge the data.

Another work around for the above senario would be to split the 
config-user.php file into multiple files -- non ideal.

> An alternative would be to make it so that the configurator never reads
> the installed config file.  Instead give the user an opportunity
> to POST a config file from which settings would be pulled.

This is more secure, but it does involve many extra steps:

1) download current config-user.php
2) Access action=configurator
3) upload current config-user.php
4) Edit
5) download new config-user.php
6) upload new config-user.php

This does also expose the database settings to man-in-the-middle attacks.

I understand that I am being extra paranoid (part of my job), so I don't 
want to veto ideas because they don't meet my needs even though they 
might be sufficient for the vast majority of other users.  Having the 
config settigs be accessable only by an administrator and using https 
should be sufficient for most users.

But from my paranoid perspective, I would like to provide a very secure 
route for configuration -- which is command line.

jbw