Ticket #8478 (closed defect (bug): fixed)

Opened 3 years ago

Last modified 3 years ago

FS Chmod 755/644 of files breaks restrictive suexec environments

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

Description

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

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

Change History

comment:1   ryan3 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?

comment:2   ryan3 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.

comment:3   DD323 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.

DD323 years ago

comment:4   DD323 years ago

  • Keywords has-patch needs-testing added

comment:5   ryan3 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

comment:6   ryan3 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.

comment:7   ryan3 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.

comment:8   DD323 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.

comment:9   DD323 years ago

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

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. ciao

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

define('FS_CHMOD_FILES','755'); define('FS_CHMOD_DIRS','755');

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

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

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

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.

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

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

define('FS_CHMOD_FILE','0755'); define('FS_CHMOD_DIR','0755'); 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.

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

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

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

and many thanx to DD32 too :-)

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

Can we close this now?

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

Can we close this now?

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

Note: See TracTickets for help on using tickets.