WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 6 years ago

#27568 closed defect (bug) (worksforme)

WordPress automatic updates are breaking unix rights

Reported by: zigooo Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.7
Component: Upgrade/Install Keywords: reporter-feedback
Focuses: Cc:

Description

On my hosted platform, PHP scripts have to be chmod +x to be executed. Otherwise, visitors are sent to an error page.

On each and every upgrade, wordpress completely destroys the unix rights of itself, removing the "world executable" bit from the PHP scripts, and adding a "world writable" bit to directories (which by the way is a very bad thing to do security wise).

This would be ok-ish if it wasn't done through the automated updates, which by the way I didn't find a way to disable (is it even possible). The result is that my blog is randomly completely broken.

Please fix the automated updates so that they don't just break unix rights each and every time.

Change History (6)

#1 @dd32
7 years ago

  • Keywords reporter-feedback added

If the automatically detected settings are not good for your system, you can define the 'FS_CHMOD_FILE' and 'FS_CHMOD_DIR' constants in your wp-config.php file, using octal notation:

define( 'FS_CHMOD_FILE', 0755 );

Ref for where WordPress sets the constants:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/file.php#L908

Previously: #20069

On each and every upgrade, wordpress completely destroys the unix rights of itself, removing the "world executable" bit from the PHP scripts, and adding a "world writable" bit to directories (which by the way is a very bad thing to do security wise).

This sounds strange to me, based on the above code, WordPress sets file permissions based on ABSPATH and ABSPATH/index.php, requiring a minimum of 755 for directories, and 644 for files, but if the executable bit is set on index.php, that should also be set by default.

Perhaps you can do some tests for us and debug the above constants to see why they're being set incorrectly?

#2 @SergeyBiryukov
7 years ago

  • Summary changed from Wordpress automatic updates are breaking unix rights to WordPress automatic updates are breaking unix rights
  • Version changed from trunk to 3.7

#3 @zigooo
7 years ago

Well, my point is that I shouldn't have to configure anything, WordPress should simply keep the unix rights that have been set. WordPress shouldn't assumes that it knows better than I do (since I'm the server administrator). I would suggest to put the FS_CHMOD_FILE by default at least, but preferably to just keep what is currently set in existing files.

And anyway, setting 777 for a directory is just plain wrong, and should be considered a security issue.

As for debugging, I can do that, if it helps solving the issue. I know PHP well (and wrote probably hunderds of thousands of lines of PHP code myself), but not WordPress, so just guide me to what you need me to test.

#4 @dd32
7 years ago

Taking a step back, WordPress aims to work with every web host out there, and unfortunately for you and I, there are some down right badly configured ones which are not the WordPress users fault. We do our best to cover the base for everyone.
The constants should not be required in your case, I simply provided them because a lot of people come needing a fix this-instant rather than debugging.

Looking at it, if you could run this code after WordPress has loaded, it'd provide a good insight into the issue:

printf(
	"Dir: %o File: %o<br>\nDir: %o File: %o\n<br>",
	fileperms( ABSPATH ),
	fileperms( ABSPATH . 'index.php' ),
	fileperms( ABSPATH ) & 0777 | 0755,
	fileperms( ABSPATH . 'index.php' ) & 0777 | 0644
);

#5 @DrewAPicture
6 years ago

@zigooo: Care to followup here following the steps in comment:4?

#6 @dd32
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Marking as worksforme for now pending reporter feedback.

The current code will respect a +x on the files, as long as PHP can see that.

Note: See TracTickets for help on using tickets.