Hello all,
I've been running the stable branches for quite a while, but wanted to branch out into the HEAD release to try some of the new features in a sandbox.
For background, I'm running Debian testing (Sarge).
I downloaded the latest software from CVS into the phase3 directory. I tried to do a command-line install using install.php but this does not appear to be working. Reading the script, some of the necessary directories are not referenced or copied in install.php. I know the install.php installation is not working in the stable branches. Is this true with the HEAD branch as well?
I decided to try the in-place install. I copied the entire phase3 directory to a place accessible by my web server and renamed it to something more appropriate (testwiki). I ran the in-place install and everything worked perfectly.
One downside with this approach is that I now have a bunch of files accessible to my web server that I am sure don't need to be there. Since a lot of this is new, I'm not sure what I can remove now that the Wiki is running, nor do I know what might be a security risk. Has anyone done a writeup on cleaning up/securing an installation of the HEAD branch? I wasn't able to find anything via Google.
The other downside is that I expect HEAD to be updated quite often. Since install.php and upgrade.php expect files to be in different locations than the in-place install, how do you update the installation to the latest version from CVS?
Thanks in advance for any help you can provide. As a side note, I am really impressed with some of the new features and especially the mono style.
-Derek
On Apr 20, 2004, at 12:42, Derek A. Rogillio wrote:
I downloaded the latest software from CVS into the phase3 directory. I tried to do a command-line install using install.php but this does not appear to be working. Reading the script, some of the necessary directories are not referenced or copied in install.php. I know the install.php installation is not working in the stable branches. Is this true with the HEAD branch as well?
The current command-line installer is being axed in favor of the in-place install (which perhaps will be improved in the future to allow a command-line execution as well as the browser-based install) We're certainly _trying_ to make the in-place installation secure, though.
I decided to try the in-place install. I copied the entire phase3 directory to a place accessible by my web server and renamed it to something more appropriate (testwiki). I ran the in-place install and everything worked perfectly.
Yay!
One downside with this approach is that I now have a bunch of files accessible to my web server that I am sure don't need to be there. Since a lot of this is new, I'm not sure what I can remove now that the Wiki is running, nor do I know what might be a security risk. Has anyone done a writeup on cleaning up/securing an installation of the HEAD branch? I wasn't able to find anything via Google.
If you'd like to do some extra security testing in case we missed something, you might try: * set PHP's error_reporting level to E_ALL to include extra notices of eg use of uninitialized variables * Go through the installation hitting every *.php and *.phtml file from a browser; see if any uninitialized variables are used (some could be potential attack vectors with register_globals off)
In particular, make sure the scripts in the maintenance directory don't execute from the web.
If you'd like to add extra precautions there are a number of things you could do: * remove install.php, update.php as they are not needed * block off the config, includes, languages, maintenance, math, extensions (if not using WikiHiero), and templates directories from the web (ie, 'Deny from all' in .htaccess or global apache config). * config and maintenance aren't needed on a _running_ installation, you can prune them (or keep copies elsewhere). * includes and languages don't have to be in the web area. You can move their contents elsewhere and set the include_path appropriately in LocalSettings.php. * math isn't needed if not using TeX; extensions isn't needed if not using WikiHiero * Move the passwords in LocalSettings.php into a file outside of the web-accessible space and include() that file. This would protect against accidental exposure of database passwords in editor backup files etc. * Make sure register_globals is off (off by default in PHP since 4.2.something)
We could perhaps add .htaccess files with 'Deny from all' into some of these directories for added protection, though they would not be active on all installations (depends on apache settings).
The other downside is that I expect HEAD to be updated quite often. Since install.php and upgrade.php expect files to be in different locations than the in-place install, how do you update the installation to the latest version from CVS?
I just do a 'cvs up'. (or 'cvs up -dP' if directories have been added or pruned.)
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
The current command-line installer is being axed in favor of the in-place install (which perhaps will be improved in the future to allow a command-line execution as well as the browser-based install) We're certainly _trying_ to make the in-place installation secure, though.
Brion,
I apologize for the delay in my reply, but I really appreciate you taking the time to help me with this. I'm implemented all of your suggestions.
Additionally, I think the Apache redirect trick forcing all URLs to reference Index.php makes a lot of sense. If you miss securing a particular data file or script it cannot be accessed directly.
I also see that the .htaccess files were checked in to CVS. This makes things extremely easy for all of us testing directly from a CVS checkout. Kudos and thanks for this!
I'm now proudly testing on the most recent CVS and have to say that so far it has been very solid. The usability improvements alone are incredible. My test users (who often run with scissors) are already pressuring me to move the new software into the main Wiki. We're all really looking forward to the next release.
Thanks again!
-Derek
mediawiki-l@lists.wikimedia.org