Last modified: 2013-07-30 00:10:51 UTC
Description of problem: [viktor@alex wiki]$ cd /var/www/wiki/ [viktor@alex wiki]$ ls -l LocalSettings.php -rw-rw-rw-. 1 apache apache 4343 Mar 4 03:38 LocalSettings.php LocalSetting.php is readable and writeable by all local users. Since this file may contain data-base credentials it shouldn't be globally-writeable. I'm not sure wether the wikimedia-installtaion script generates this file, so it may not be fixable in the rpm-package (I'm using the rpm provided by FedoraCore16), but in the mediawiki-source. As far as I understood the error is in installer/LocalSettingsGenerator.php [1]; 142 /** 143 * Write the generated LocalSettings to a file 144 * 145 * @param $fileName String Full path to filename to write to 146 */ 147 public function writeFile( $fileName ) { 148 file_put_contents( $fileName, $this->getText() ); 149 } The file_put_contents-call seems to use the default umask. [1] which i took from: svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/installer/LocalSettingsGenerator.php Since I'm not a PHP-programmer, I hope someone with more knowdlege can confirm my observation (maybe with an fresh install from svn). regards Viktor Version-Release number of selected component (if applicable): 1.16.5-59.fc16
Don't use a package of MediaWiki (they aren't usually updated, or they silly things), grab the tarball from our site instead. The install these days doesn't even try to save the file for you, The user needs to download it locally and then move it over to the webserver into the MW folder (and chmod it appropriately). Suggesting, WONTFIX for this.
(In reply to comment #1) > Don't use a package of MediaWiki (they aren't usually updated, or they silly > things), grab the tarball from our site instead. > > The install these days doesn't even try to save the file for you, The user > needs to download it locally and then move it over to the webserver into the MW > folder (and chmod it appropriately). > > > Suggesting, WONTFIX for this. If you use the command line installer, it does indeed write the file. So this could be a bug.
Must be caused by apache having an invalid umask. On fedora have a look at /etc/sysconfig/httpd and set the umask to a sane default such as 'umask 002'. If you have a default fedora core configuration, you really want to report the bug to them so they can fix their apache umask. Lowering severity, it is not that bad and most probably caused by a local, non MediaWiki, user configuration.
(In reply to comment #1) > The install these days doesn't even try to save the file for you, The user > needs to download it locally and then move it over to the webserver into the > MW folder (and chmod it appropriately). Of course every sysadmin should check permissions of config-files him/herself, nevertheless I would prefer MW to check/set the permissions if not appropriate. (In reply to comment #1) > The install these days doesn't even try to save the file for you, The user > needs to download it locally and then move it over to the webserver into the > MW folder (and chmod it appropriately). In svnroot/mediawiki/tags/REL1_9_6/phase3/config/index.php umasking the file is still not performed, see below; (if that's the right file and I haven't overlooked something) (In reply to comment #3) > Must be caused by apache having an invalid umask. On fedora have a look at > /etc/sysconfig/httpd and set the umask to a sane default such as 'umask 002'. I think MW's installation routine should be fault-tolerant, to also handle umask-madness ;-) LocalSettingsGenerator.php in mediawiki-1.18.1 tarball [1] 142 /** 143 * Write the generated LocalSettings to a file 144 * 145 * @param $fileName String Full path to filename to write to 146 */ 147 public function writeFile( $fileName ) { 148 file_put_contents( $fileName, $this->getText() ); 149 } [1] file from mediawiki-1.18.1/includes/installer in index.php from svnroot/mediawiki/tags/REL1_9_6/phase3/config/index.php': there still is: 918 $f = fopen( "LocalSettings.php", 'xt' ); [...] 925 if(fwrite( $f, $localSettings ) ) { 926 fclose( $f ); 927 writeSuccessMessage(); which neither handles umask; (I've just watched the source, haven't it tried out in an installation). Did i grep the right file? I'm a bit confused with the svn-directory structure. > If you have a default fedora core configuration, you really want to report the > bug to them so they can fix their apache umask. Bug is already reported in Fedora-Bugzilla: 799659 https://bugzilla.redhat.com/show_bug.cgi?id=799659 > Lowering severity, it is not that bad and most probably caused by a local, non > MediaWiki, user configuration. Database user credentials are stored in plain-text, thus IMHO this is severe. I don't think the distributor's umask should permit read-access for all-users on the system, since in /var/www usually is meant to be public - except for configuration-files. In the above code-example MW doens't try to set the right (more restrictive) umask, which would be it's responsibility (again IMHO).
(In reply to comment #4) > in index.php from svnroot/mediawiki/tags/REL1_9_6/phase3/config/index.php': > there still is Do you realise that 1.9 was 5 years ago? ;)
(In reply to comment #5) > Do you realise that 1.9 was 5 years ago? ;) oops, yah, hmm - ah, sometimes i live in the past ;-) I just found out, that the topic was already discussed in Bug: 24133 Nevertheless I tried it with the command-line installer using this branch: svnroot/mediawiki/trunk/phase3/ (which should be 1.20 alpha). If I'm not confused too much this time (right branch?) the CLI script produces a globally-readable file, while the web-installer forwards the task to the sysadmin to take care of the right umask, when copying the file. [root@alex w]# php maintenance/install.php --dbuser testwikiuser --dbpass NotForYou --installdbpass NotForYou --installdbuser root --pass NotForYou test WikiSysop PHP 5.3.10 is installed. Warning: Could not find APC, XCache or WinCache. Object caching is not enabled. Found ImageMagick: /usr/bin/convert. Image thumbnailing will be enabled if you enable uploads. Using server name "http://alex.wg". Warning: No --scriptpath specified, using default: /wiki. Using server URL "http://alex.wg/wiki". Warning: Your default directory for uploads (/var/www/w/images/) is not checked for vulnerability to arbitrary script execution during the CLI install. Warning: The intl PECL extension is not available to handle Unicode normalization, falling back to slow pure-PHP implementation. If you run a high-traffic site, you should read a little on Unicode normalization. The environment has been checked. You can install MediaWiki. Setting up database done Creating tables Warning: MediaWiki tables seem to already exist. Skipping creation. done Creating database user done Populating default interwiki table Warning: The interwiki table seems to already have entries. Skipping default list. done Initializing statistics done Generating secret keys done Creating administrator user account done Creating main page with default content done [root@alex w]# ls -l LocalSettings.php -rw-r--r--. 1 root root 4487 Mar 4 19:04 LocalSettings.php
(In reply to comment #6) <snip> > [root@alex w]# php maintenance/install.php --dbuser testwikiuser --dbpass > NotForYou --installdbpass NotForYou --installdbuser root --pass NotForYou test <snip> > [root@alex w]# ls -l LocalSettings.php > -rw-r--r--. 1 root root 4487 Mar 4 19:04 LocalSettings.php What is the point of that test? You could have verified that your root user as a 0022 umask just by doing: $ touch /tmp/fooumask $ ls -l /tmp/fooumask -rw-r--r-- 1 root root 0 some_date /tmpfooumask $ Try again with 1.18 and you will get the same result. Please note that in the above case, file belonging to root:root, you need the other user to be able to read the file or apache will not be able to read the file. If the file belong to apache:apache , even as r--r-----, any user able to host files on your server will be able to read it just by doing: file_get_contents( '/var/www/yourwiki/LocalSettings.php');
(In reply to comment #7) > (In reply to comment #6) > <snip> > > [root@alex w]# php maintenance/install.php --dbuser testwikiuser --dbpass > > NotForYou --installdbpass NotForYou --installdbuser root --pass NotForYou test > <snip> > > [root@alex w]# ls -l LocalSettings.php > > -rw-r--r--. 1 root root 4487 Mar 4 19:04 LocalSettings.php > > What is the point of that test? You could have verified that your root user as > a 0022 umask just by doing: I just wanted to show that install.php creates a config-file containing data-base credentials that's readable by the other-group (from locally logged in users) - it could behave differently (using PHP's chmod). Since I've never programmed any PHP and have only little knowdlege about apache's php-integration, please tell me if I'm totally wrong. > If the file belong to apache:apache , even as r--r-----, any user able to host > files on your server will be able to read it just by doing: > file_get_contents( '/var/www/yourwiki/LocalSettings.php'); Yep, this is suboptimal. Nevertheless I think it's much wiser to only allow apache-users (group) to read the file, than to allow it everyone. Other php-projects handle this issue similar, e.g. wordpress: "... All files should be 644 or 640. Exception: wp-config.php should be 600 to prevent other users on the server from reading it. ..." from: http://codex.wordpress.org/Changing_File_Permissions
Removing upstream keyword since the bug summary was changed from Fedora Core only issue to having a fix build in MediaWiki.
