Opened 16 years ago
Closed 16 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: |
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 (1)
Change History (24)
#2
@
16 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
@
16 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.
#5
@
16 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
@
16 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
@
16 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
@
16 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
@
16 years ago
Also, I'll look at that error you posted tonight and add some error catching into the code.
#10
@
16 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.
ciao
#11
@
16 years ago
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');
#14
@
16 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
@
16 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.
#17
@
16 years ago
I also tried define('FS_CHMOD_FILE','755'); define('FS_CHMOD_DIR','755'); but always 500
#18
@
16 years ago
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.
#19
@
16 years ago
try this, Its a Octal number, Not a String.
define('FS_CHMOD_FILE',0755); define('FS_CHMOD_DIR',0755);
They don't like any group other other read permissions? Or maybe they don't like any write permissions even for the owner?