WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#14753 closed defect (bug) (duplicate)

Automatic Upgrade Breaks when Owner in *NIX is not Web Server user

Reported by: captbrando Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.1
Component: Upgrade/Install Keywords:
Focuses: Cc:

Description

After troubleshooting an automatic upgrade issue off and on for about a year, I think I have finally discovered the issue that caused the auto upgrade to fail.

IN this setup, I had a user with their own directory and site. Their unix user ID owned the directory and files, and the webserver's group had write access to all the files (verified in the apache config that it was using that group).

The automatic upgrade ONLY worked when I changed the user ownership to that of the webserver user ID. I did nothing to permissions, just changed who owned the file, then the automatic upgrade worked. This should not be how wordpress works, as from a permissions perspective, it has access to modify anything inside those directories (under the group write permission bit). I'm not sure WHICH file changed the behavior, but when I changed all the wp* files recursively to be owned by the webserver, it worked.

Change History (3)

comment:1 jnovak4 years ago

I've discovered the same problem on a clean install -- the "automatic upgrade" option for plugins or WordPress itself, or the installation of new plugins or themes sends me to the FTP credentials page instead of just doing the in-place upgrade/install.

After a lot of troubleshooting, I narrowed it down to three files in the wp-admin directory needing to be owned by the webserver's user:

wp-admin/plugins.php
wp-admin/themes.php
wp-admin/update.php

As long as I chown those to the webserver user, as well as ensuring that the wp-content directory has the appropriate permissions/ownership, everything works fine. If those three wp-admin files are not owned by the webserver user, the in-place upgrade/install won't be attempted.

Since those three files should never be touched outside of a complete upgrade of WordPress itself, this behavior seems very wrong.

comment:2 dd324 years ago

See also #10205

IN this setup, I had a user with their own directory and site. Their unix user ID owned the directory and files, and the webserver's group had write access to all the files (verified in the apache config that it was using that group).

This is because the upgrade proceedure checks the ownership of the created files, and specifically, only the username, NOT the groupname. This is basically due to the 'direct' WP_Filesystem class (Direct Flie I/O) being designed to work under suExec/suPHP scenario's, which are the only real "guarantee'd" scenario's which upgrading via that method will result in a 100% user-owned files.

Write access to the directory is not enough, The files created MUST be OWNED by the same user as the WordPress files themselves.

An example of a scenario where we do not want the 'direct' class to be used, is this:

  • Apache running as u/g www-data/www-data
    • Files created by apache as u/g www-data/www-data
  • Users publc_html folders being owned as u/g johndoe/www-data

In the above case, a user accessing his account via FTP would be prompted with a list of files which are not owned by his login, and therefor, unmanagable.

comment:3 scribu4 years ago

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

Gonna close this as dup of #10205 since (I assume) it has the same cause.

Note: See TracTickets for help on using tickets.