Last modified: 2010-05-15 16:03:25 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16593, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14593 - Do not create new directories with permission 777
Do not create new directories with permission 777
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.13.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 11209
  Show dependency treegraph
 
Reported: 2008-06-19 17:33 UTC by Jack Bates
Modified: 2010-05-15 16:03 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Jack Bates 2008-06-19 17:33:55 UTC
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
Comment 1 Roan Kattouw 2008-06-19 18:19:49 UTC
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.
Comment 2 Daniel Friesen 2008-06-20 16:00:16 UTC
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.
Comment 3 Chad H. 2008-07-16 18:37:46 UTC
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.
Comment 4 Chad H. 2008-08-10 16:07:14 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links