Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#8478 closed defect (bug) (fixed)

FS Chmod 755/644 of files breaks restrictive suexec environments

Reported by: DD32 Owned by:
Milestone: 2.7 Priority: normal
Severity: blocker Version: 2.7
Component: Upgrade/Install Keywords: reporter-feedback
Focuses: Cc:


Aparantly when running under suexec, some hosts (particually italian) use restricrive file permissions (400 in general) for all user files, and refuse to access files which have group or world permissions set.

As a result, The plugin upgrader, and now core upgrader functionality appears to be broken for many italian users.

The bet fix (I can think of) would be to define some constants for the chmod's of new files and folders, and allow users to either define them manually, or guess them by setting them to the current /wp-settings.php and /wp-includes/ permissions.

I'm going to attempt to work a patch in around this.

Attachments (1)

8478.diff (7.4 KB) - added by DD32 13 years ago.

Download all attachments as: .zip

Change History (24)

#1 @ryan
13 years ago

They don't like any group other other read permissions? Or maybe they don't like any write permissions even for the owner?

#2 @ryan
13 years ago

In general, I think 444 and 555 might be good defaults for suexec environments. A define or guessing from permissions on existing dirs would still be needed for special cases like 400, as you say.

#3 @DD32
13 years ago

Just thinking about it, I've come accross a suexec environment in the past (before WP times) where any file which had ANY permission for group/world would cause suexec to kick in and prevent the sky from falling.

I've knocked up a patch (and found a few bugs in the filesystem code) which uses constants with default values based on wp-settings.php and wp-includes/ It needs some serious testing though.. Defaulting to 644/755 instead for the constants is a possible option for 2.7 & leaving the guessing for 2.7.1, but thats not a ideal situation, But if testing finds any problems with my patch, that's what i'd suggest happen.

13 years ago

#4 @DD32
13 years ago

  • Keywords has-patch needs-testing added

#5 @ryan
13 years ago

Hit this during upgrade after playing with permissions. We should catch this.

[03-Dec-2008 16:41:09] PHP Warning:  dir(/Applications/MAMP/htdocs/trunk/wp-content/upgrade/core/) [<a href='function.dir'>function.dir</a>]: failed to open dir: Permission denied in /Applications/MAMP/htdocs/trunk/wp-admin/includes/class-wp-filesystem-direct.php on line 235
[03-Dec-2008 16:41:09] PHP Fatal error:  Call to a member function read() on a non-object in /Applications/MAMP/htdocs/trunk/wp-admin/includes/class-wp-filesystem-direct.php on line 236

#6 @ryan
13 years ago

That's because upgrade/core is being created with funky perms (d---r-xr-x). Perms for wp-includes are drwxr-xr-x.

#7 @ryan
13 years ago

Maybe do this for 2.7: Default suexec installs to 444 and 555 and add the constants for override. Drop all of the other changes.

#8 @DD32
13 years ago

Yeah, Theres probably too many bugs in the current setup to do it the way i've patched.

The problem with defaulting to 444 and 555 for suexec setups, is that by default, they're designed to work with 644/755, And the only setups that i've seen/heard of having problems, are those which -need- 0 for group/world, So 600 for files (read/write for owner, everyone else leave it alone)

(And who in their right mind would setup a server where the owner of a file cannot write to it? - that means deletion could have problems)

I'm tempted to suggest defaulting the constants to 644/755(Since its working well for most people) and allowing those who have troubles with it to define something custom - Until at least, its possible to determine what changes need to be made specifically to support the edge cases.

#9 @DD32
13 years ago

Also, I'll look at that error you posted tonight and add some error catching into the code.

#10 @wolly
13 years ago

Thanx a lot for the patch.
I've installed the patched verions but i get the same errors of ryan.

Warning: dir(/web/htdocs/www.micasiamocuochima.org/home/test27/wp-content/upgrade/core/) [function.dir]: failed to open dir: Permission denied in /web/htdocs/www.micasiamocuochima.org/home/test27/wp-admin/includes/class-wp-filesystem-direct.php on line 235

Fatal error: Call to a member function read() on a non-object in /web/htdocs/www.micasiamocuochima.org/home/test27/wp-admin/includes/class-wp-filesystem-direct.php on line 236

If you need I can give you access to the testing blog.

#11 @wolly
13 years ago

I have defined the constants in the wp-config and I get the some errors.


#12 @ryan
13 years ago

(In [10050]) Allow override of default file permissions with FS_CHMOD_DIR and FS_CHMOD_FILE. Props DD32. see #8478

#13 @ryan
13 years ago

(In [10051]) Check return of dir(). see #8478

#14 @wolly
13 years ago

I tried with the two patch, the upgrade was fine but I always have the problem with the permisions, it doesn't read the define('FS_CHMOD_FILES','755'); define('FS_CHMOD_DIRS','755'); I put in the wp-config.
It doesn't work also I use the normal wp-config without the define('FS_CHMOD_FILES','755'); define('FS_CHMOD_DIRS','755');
So I always have the error 500

#15 @DD32
13 years ago

it doesn't read the define('FS_CHMOD_FILES','755'); define('FS_CHMOD_DIRS','755');

Quite possibly because they're named 'FS_CHMOD_FILE' and 'FS_CHMOD_DIR', no plurals.

Error 500: I assume this is what occurs when you attempt the upgrade, and it fails? That doesnt sound like this is the solution to that at all honestly.

#16 @ryan
13 years ago

Also, use 0755 not '755'. An octal number is required, not a string.

#17 @wolly
13 years ago

I also tried define('FS_CHMOD_FILE','755'); define('FS_CHMOD_DIR','755'); but always 500

#18 @wolly
13 years ago

I receive the message that the upgrade was succesfully but as I clik everywhere i receive this error:(permissions I see on the server after the upgrade are dirs 755 files 644)

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, postmaster@… and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

#19 @DD32
13 years ago

try this, Its a Octal number, Not a String.


#20 @wolly
13 years ago

Ok Ryan, now it works :-) Thanx Thanx a lot!!!!

#21 @wolly
13 years ago

and many thanx to DD32 too :-)

#22 @westi
13 years ago

  • Keywords reporter-feedback added; has-patch needs-testing removed

Can we close this now?

#23 @DD32
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Can we close this now?

For 2.7, Yes. Those affected (minority) can define the constants.

Note: See TracTickets for help on using tickets.