Page MenuHomePhabricator

Do not create new directories with permission 777
Closed, ResolvedPublic

Description

Author: ms419

Description:
When uploading images to MediaWiki, I notice it creates new directories with permission 777. Since I have installed MediaWiki on a shared host, I prefer new directories to be created with permission 755, to prevent other users on the shared host from writing to them.

Where Apache and PHP are run with the same user id, I would even prefer new directories to be created with permission 770, to prevent other users from even reading them. However this is not the case on my shared host: Apache is run as www-data and PHP is run as my user id.

I cannot think of a case where I want new directories to be created with permission 777.

Thanks and best wishes, Jack


Version: 1.13.x
Severity: enhancement

Details

Reference
bz14593

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:13 PM
bzimport set Reference to bz14593.
bzimport added a subscriber: Unknown Object (MLST).

Maybe we could add a $wg variable to LocalSettings.php specifying which chmod newly created directories should have? Another such variable for newly created files could be useful too.

Might be a little tricky with how much MW completely avoids these function calls.

In between includes/media/Bitmap.php:207/208 sounds like a good spot for chmoding. A similar area for other media types.

As for directory building, we already have a function which accepts a chmod, though it is used a bit much, and in pretty ugly ways:

includes/filerepo/FSRepo (6)
128: FSRepo::storeBatch: "if ( !wfMkdirParents( $this->directory ) ) {"
149: FSRepo::storeBatch: "if ( !wfMkdirParents( $dstDir ) ) {"
261: FSRepo::publishBatch: "if ( !wfMkdirParents( $this->directory ) ) {"
286: FSRepo::publishBatch: "if ( !is_dir( $dstDir ) && !wfMkdirParents( $dstDir ) ) {"
289: FSRepo::publishBatch: "if ( !is_dir( $archiveDir ) && !wfMkdirParents( $archiveDir ) ) {"
392: FSRepo::deleteBatch: if ( !wfMkdirParents( $archiveDir ) ) {"
includes/Math.php (2)
150: MathRenderer::render "if( !@wfMkdirParents( $hashpath, 0755 ) ) {"
220: MathRenderer::_recall "if( !@wfMkdirParents( $hashpath, 0755 ) ) {"
includes/media/Bitmap.php (1)
91: BitmapHandler::doTransform: "if ( !wfMkdirParents( dirname( $dstPath ) ) ) {"
includes/media/DjVu.php (1)
93: DjVuHandler::doTransform:"if ( !wfMkdirParents( dirname( $dstPath ) ) ) {"
includes/media/SVG.php (1)
59: SvgHandler::doTransform:"if ( !wfMkdirParents( dirname( $dstPath ) ) ) {"
includes/MessageCache.php (2)
113: MessageCache::saveToLocal: "wfMkdirParents( $wgLocalMessageCache, 0777 ); might fail"
134: MessageCache::saveToScript: "wfMkdirParents( $wgLocalMessageCache, 0777 );
might fail"
includes/specials/Revisiondelete.php (1)
1204: RevisionDeleter::makeOldImagePublic: "wfMkdirParents( $destDir );"

Perhaps we could make the 2nd parameter also accept a chmod class string. Something like 'imagedir' and it'll grab a predefined chmod for that group of files. Make one for 'imagedir' and another for 'messagecache'. Also, we may want a cleaner method for ensuring chmod settings of image files. We could either use a GlobalFunction or create another method inside of the generic media type and call that to do the work.

Partially fixed in r37756, allows customizing the default Chmod value. There's still some hardcoded ones here and there (a grep for 777 shows where), but I haven't touched those yet.

r38900 removed the last of the hardcoded 0777 values. Note that some hardcoded permissions still exist and need cleanup, but the request for non-777 permissions has been cleared up. See bug 11209 for the rest of the work on this.