Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Re $wgDefaultDirectoryChmod (r37756)

 

 

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


brion at wikimedia

Jul 17, 2008, 2:40 AM

Post #1 of 3 (175 views)
Permalink
Re $wgDefaultDirectoryChmod (r37756)

demon[at]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[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


innocentkiller at gmail

Jul 17, 2008, 5:42 AM

Post #2 of 3 (159 views)
Permalink
Re: Re $wgDefaultDirectoryChmod (r37756) [In reply to]

On Thu, Jul 17, 2008 at 5:40 AM, Brion Vibber <brion[at]wikimedia.org> wrote:
> demon[at]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[at]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

_______________________________________________
Wikitech-l mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


brion at wikimedia

Jul 17, 2008, 7:08 AM

Post #3 of 3 (153 views)
Permalink
Re: Re $wgDefaultDirectoryChmod (r37756) [In reply to]

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 mailing list
Wikitech-l[at]lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.