Generally speaking I advocate for contributed modules going into: sites/all/modules, base themes into sites/all/themes and site-specific themes into whatever folder has the settings file for the site. In the case of a multisite install this is sites/example.com/themes, but in a single-site install it's sites/default/themes.

In working with 100 or so novice D7 themers over the last month a number of folks have found it utterly confusing that the default folder isn't writable, and therefore you can't make a new directory to add a theme via FTP.

When Drupal is first unpacked, the permissions are as follows:
drwxr-xr-x 4 www-data www-data 4.0K 2011-01-05 01:25 all
drwxr-xr-x 2 www-data www-data 4.0K 2011-01-05 01:25 default <--- owner can "write"
-rw-r--r-- 1 www-data www-data 1.9K 2010-04-15 08:01 example.sites.php

After the install is complete the permissions are as follows:
drwxr-xr-x 4 www-data www-data 4.0K 2011-01-05 01:25 all
dr-xr-xr-x 3 www-data www-data 4.0K 2011-03-01 16:51 default <--- note, no "write" for anyone
-rw-r--r-- 1 www-data www-data 1.9K 2010-04-15 08:01 example.sites.php

Modules and themes that are uploaded via the UI get dumped into sites/all/themes. Settings folders that are created by the Drupal are usually placed into sites/files (with no problems).

It makes sense that we don't want the "live" site folder to be writable and therefore have malicious scripts uploaded to it which alter the settings file; however, the inability to add a "themes" folder to the default folder is ... well .. very difficult to explain.

Feature request: add a themes folder to sites/default.

Alternate feature request: add a README.txt to sites/default that tells people to (1) change the permissions or (2) add their themes to sites/all/themes.

[edit, march 4, 2011] updated the language around permissions to clarify the problem

Comments

emmajane’s picture

emmajane CreditAttribution: emmajane commented

Adding docs team tag.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

When the site is first installed the permissions are as follows:
drwxr-xr-x 4 www-data www-data 4.0K 2011-01-05 01:25 all
drwxr-xr-x 2 www-data www-data 4.0K 2011-01-05 01:25 default
-rw-r--r-- 1 www-data www-data 1.9K 2010-04-15 08:01 example.sites.php

How did you wind up with the "www-data" user as owner of those directories? Those would normally be owned by the user themselves (i.e., the FTP user). That seems to me like it's one of the main causes of this issue. Or am I misunderstanding your server setup?

If the FTP user owns those directories, then they can change its permissions and add a themes folder later with no problem (although of course, they do have to figure out how to use their FTP program to change the folder permissions - maybe you are saying that is the barrier they are facing here).

In any case, I do think it's the case that the way the installer deals with write permissions isn't always sensible. Some of it is necessary for security (on certain server setups, but not others), but in general it seems to me like it isn't really consistent in how it handles this - would need to look more carefully though. Having sites/default writable by (or owned by) the webserver is not good in general, but it's an equal security risk to having other parts of the codebase writable/owned by the webserver, and the installer seems to focus like a laser on sites/default for whatever reason.

grendzy’s picture

grendzy CreditAttribution: grendzy commented
Issue tags: +DrupalWTF

I think we should remove this chmod behavior from system_requirements. It has no security benefit whatsoever, since the other 500 or so PHP files are unchecked.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Perhaps, but that won't really help this issue since the chmod behavior also occurs in the installer (where it does have a security benefit under some conditions, though a minimal one). And the reason system_requirements() needs to special-case these files is because the installer did. So we definitely shouldn't remove the warnings from the reports page altogether, but I agree that having it try to "helpfully" chmod() those files every time you visit the reports page may not be the right behavior :)

Either way, I think I like @emmajane's suggestion as something simple that can help here (part of it even for Drupal 7)... i.e., add sites/default/modules, sites/default/themes and sites/default/README.txt. This would nicely parallel what's already in sites/all.

emmajane’s picture

emmajane CreditAttribution: emmajane commented

@David_Rothstein take a look at the permissions post-install again. It doesn't matter who the owner is, the permissions are r-x for all three (owner, group, everyone).

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

The owner definitely does matter. In one case they literally won't be able to create sites/default/themes at all (no matter what they try), whereas in the other case they can technically do it, but might not know how (since changing directory permissions via an FTP program is not always a straightforward task).

Either way, I get your point - this puts new users in a difficult-to-understand situation :)

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
CreditAttribution: tim.plunkett commented
Issue tags: +Needs documentation

Fixing tags

Version: 7.0 » 7.x-dev

Core issues are now filed against the dev versions where changes will be made. Document the specific release you are using in your issue comment. More information about choosing a version.