demon@svn.wikimedia.org wrote:
Log Message:
Add $wgDefaultDirectoryChmod, allows customizing the default chmod value. Set to 0777 by default to keep current behavior.
Handy... I think there's some other uses of mkdir() directly which should presumably have this default setting applied to them as well...
I'm not super fond of the name though -- maybe $wgDirectoryMode ? :) Anyway...
Compare also with the patch on this old bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=6295
and further notes on: https://bugzilla.wikimedia.org/show_bug.cgi?id=14593
We've got similar issues where we may need to be able to override the default permission mode for thumbnail files, see: https://bugzilla.wikimedia.org/show_bug.cgi?id=6654
Check also texvc, see if old issues there have changed: https://bugzilla.wikimedia.org/show_bug.cgi?id=6248
-- brion
On Thu, Jul 17, 2008 at 5:40 AM, Brion Vibber brion@wikimedia.org wrote:
demon@svn.wikimedia.org wrote:
Log Message:
Add $wgDefaultDirectoryChmod, allows customizing the default chmod value. Set to 0777 by default to keep current behavior.
Handy... I think there's some other uses of mkdir() directly which should presumably have this default setting applied to them as well...
I'm not super fond of the name though -- maybe $wgDirectoryMode ? :) Anyway...
Compare also with the patch on this old bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=6295
and further notes on: https://bugzilla.wikimedia.org/show_bug.cgi?id=14593
We've got similar issues where we may need to be able to override the default permission mode for thumbnail files, see: https://bugzilla.wikimedia.org/show_bug.cgi?id=6654
Check also texvc, see if old issues there have changed: https://bugzilla.wikimedia.org/show_bug.cgi?id=6248
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The patch on bug 6295 is largely obsolete, as wfImageDir() and friends are no longer in the code. I've closed it as FIXED.
I didn't change any of the hard-coded chmod values (even the 0777's) yet because of things like bug 6654 where an explicit permission is required. At the same time, I don't think churning out a million new config variables for each different permission level we want is the right course of action. I can see all of the 0777's being changed to the new variable, but I think leaving the hard-coded ones as-is for now would be best.
-Chad
Chad wrote:
The patch on bug 6295 is largely obsolete, as wfImageDir() and friends are no longer in the code. I've closed it as FIXED.
Woohoo!
I didn't change any of the hard-coded chmod values (even the 0777's) yet because of things like bug 6654 where an explicit permission is required.
Well, to summarize the issue:
When you create a new file or directory on a Unix system, it gets a default set of permissions which is determined based on the 'umask' in the environment. (Details in http://en.wikipedia.org/wiki/Umask for those not familiar with how it works.)
Most of the time, this will be a file/dir that anyone can read, but only the file owner can change. (More or less.)
Now, when working in a LAMP environment we usually have a few issues:
* A specific user account often owns the site's code files (some random user like 'brion' or sometimes a system-wide 'root'). This user needs read/write access to the directories and at least read access to the uploaded/generated files so he can run his own maintenance scripts, and back up his files.
* A different, restricted account often is running the web scripts (like 'apache' or 'www-data'). This user needs read/write access to the directories so it can create and delete files, and read access to the uploaded files so it can generate thumbnails from them.
A typical default umask leaves directories created by the web script *visible* to the "real" owner, but not changeable, making it tough to manage the files... and sometimes a restrictive umask leaves them even unreadable.
Hence we throw in the 777s to ensure that both user accounts can read and write. In some shared hosting environments the actual site owner's account runs the web scripts as well, making this unnecessary, and it's safer to use a more restrictive mode -- in which case having a setting for it in the software is nice.
Most of the time we don't have to override the mode on the individual files, since they only have to be readable by both users (they can still be deleted due to the directory permissions). But when the umask is crazy restrictive, as apparently in the case of the reporter for bug 6654, then it would be nice to override that, too.
This shouldn't require a separate setting for every file created, just a general sort of "umask override" option to set a mode for files the wiki creates.
-- brion
wikitech-l@lists.wikimedia.org