We are an open source project and we have an Apache web server with a MediaWiki 1.25. Its a stand alone installation, so we don't have the complications of shared hosting a varying userids. After 20 years or so and a few migrations we had a fair amount files owned by "no user" and "no group".
We cleaned up the file system permissions by effectively setting permissions on files and directories to root:apache
, where owner was entitled with rw
and group was entitled with r
. It was not haphazard; rather we identified missing permissions with commands like find /var/www -nouser
, find /var/www -nogroup
, find /var/www \! -user root
and find /var/www \! -group apache
.
We also identified two special cases: root:root
and apache:apache
and reset the permissions. root:root
was reset because it meant the file was not accessible to the web server. apache:apache
was reset because it meant a high risk component had write permissions.
Problem: We managed to break MediaWiki uploads and thumbnails, which I believe was caused by the apache:apache
reset. It is mostly OK because admins use the feature and we know what caused the break. I'm now trying to correct the break, but I can't determine what the file system permissions are supposed to be. Searching is revealing the application level permissions for items like LocalSettings.php
and $wgGroupPermissions
. And the MediaWiki Architecture docs don't discuss it.
Question: What are the filesystem permission supposed to be for a MediaWiki installation in a non-shared configuration?
For completeness, "non-shared" means the "single user" use case from the cited What permissions should my website files/folders have on a Linux webserver? The VM is dedicated to us, and there's a single Apache, MediaWiki and MySQL user (MediaWiki appears to piggy-back on Apache, so there are only Apache and MySQL users).
We are not in a shared hosting environment with different instances of Apache and MediaWiki running under different user contexts or with different file permissions for each distinct subscriber.
Here is the exception when I attempt to upload a file. I used to be able to upload it when filesystem permissions were "fast and loose":
[724f5260] /wiki/Special:Upload MWException from line 1856 of /var/www/html/w/includes/filerepo/file/LocalFile.php: Could not acquire lock for 'Vs2005-dynamic.zip.'
Backtrace:
#0 /var/www/html/w/includes/filerepo/file/LocalFile.php(1148): LocalFile->lock()
#1 /var/www/html/w/includes/upload/UploadBase.php(715): LocalFile->upload(string, string, boolean, integer, array, boolean, User)
#2 /var/www/html/w/includes/specials/SpecialUpload.php(476): UploadBase->performUpload(string, boolean, boolean, User)
#3 /var/www/html/w/includes/specials/SpecialUpload.php(195): SpecialUpload->processUpload()
#4 /var/www/html/w/includes/specialpage/SpecialPage.php(384): SpecialUpload->execute(NULL)
#5 /var/www/html/w/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run(NULL)
#6 /var/www/html/w/includes/MediaWiki.php(267): SpecialPageFactory::executePath(Title, RequestContext)
#7 /var/www/html/w/includes/MediaWiki.php(566): MediaWiki->performRequest()
#8 /var/www/html/w/includes/MediaWiki.php(414): MediaWiki->main()
#9 /var/www/html/w/index.php(41): MediaWiki->run()
#10 {main}
Here are the users contexts for the running web server.
$ sudo ps aux | egrep -i '(apache|http|media|wiki)'
root 127 0.0 1.2 552216 13424 ? Ss 01:35 0:12 /usr/sbin/httpd -DFOREGROUND
apache 7318 0.5 2.5 564804 27140 ? S 11:57 0:05 /usr/sbin/httpd -DFOREGROUND
apache 7346 0.3 2.4 565124 25548 ? S 11:58 0:03 /usr/sbin/httpd -DFOREGROUND
apache 7351 0.6 3.4 574220 36580 ? S 11:58 0:05 /usr/sbin/httpd -DFOREGROUND
apache 7477 0.1 1.3 554088 14012 ? S 12:10 0:00 /usr/sbin/httpd -DFOREGROUND
apache 7487 0.9 2.9 571148 30632 ? S 12:11 0:00 /usr/sbin/httpd -DFOREGROUND
The MediaWiki 1.27 migration is planned. We are holding off until we get the permissions correct.
chmod -R 0700
this will allow only the owner to read, write and excute.chmod -R 0700
..." - OK, thanks. Where do these tweaks need to be performed? (This is my pain point - I can't find a governing document for best practices or guide to loosening security from a firmer posture).