[wp-trac] [WordPress Trac] #14753: Automatic Upgrade Breaks when Owner in *NIX is not Web Server user
WordPress Trac
wp-trac at lists.automattic.com
Sat Sep 25 12:46:09 UTC 2010
#14753: Automatic Upgrade Breaks when Owner in *NIX is not Web Server user
-----------------------------+----------------------------------------------
Reporter: captbrando | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Upgrade/Install | Version: 3.0.1
Severity: normal | Keywords:
-----------------------------+----------------------------------------------
Comment(by dd32):
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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/14753#comment:2>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list