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