Page MenuHomePhabricator

CLI-installer generates globally-readable LocalSettings.php
Open, MediumPublic

Description

Author: viktor

Description:
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


Version: 1.20.x
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=24133

Details

Reference
bz34945

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:10 AM
bzimport set Reference to bz34945.
bzimport added a subscriber: Unknown Object (MLST).

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.

viktor wrote:

(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? ;)

viktor wrote:

(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');

viktor wrote:

(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.