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