WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#10895 closed defect (bug) (worksforme)

theme upload / delete fails due to update.php / themes.php ownerhip

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

Description

Wordpress 2.8.4 theme uploads through the admin UI are failing due to a file ownership issue, even when file ownership and permissions are set exactly as recommended in the Wordpress docs:

"All files should be owned by your user account on your web server, and should be writable by your username. Any file that needs write access from WordPress should be group-owned by the user account used by the webserver."
"For core WordPress files, all should be writable only by your user account."
http://codex.wordpress.org/Changing_File_Permissions
http://wordpress.org/docs/en/handbook/2.7/#sysadmin.permissions

I had the ownerships and permissions set exactly as recommended by the wordpress web site, yet uploading a theme still failed. It also failed when I gave the wordpress/apache process full permissions on *every* file and directory in the whole installation. It finally worked when I changed the ownership of "wp-admin/update.php" to be that of the apache user. Mind you, wordpress already had full rights to that file; changing the ownership didn't give it any more abilities than it already had.

It seems wordpress is arbitrarily failing because it thinks update.php should be owned by the apache user, even though that goes contrary to wordpress.org recommendations and standard unix security practices.

There is a similar problem deleting a theme when "wp-admin/themes.php" is not owned by the apache user.

Change History (5)

comment:1 follow-up: @dd326 years ago

  • Component changed from General to Upgrade/Install
  • Keywords reporter-feedback added

Unfortunately both of those resources you've refered to do NOT make reference to the upgrade/install process.

you should NOT have to change the ownership of the files, or the permission levels. WordPress does NOT access the files directly.

WordPress uses FTP to modify the files (Unless WordPress is in a suPHP/SuExec environment, Or you've messed with ownership/permissions), It'd be much appreciated if you'd report the original error you came up against.

comment:2 in reply to: ↑ 1 ; follow-up: @foresto6 years ago

Replying to dd32:

Unfortunately both of those resources you've refered to do NOT make reference to the upgrade/install process.

I'm not sure I understand you. Are you trying to say that the two PHP files I mentioned do not contain code that is used in the theme install process? That may be the case, but the problem I described still exists.

you should NOT have to change the ownership of the files, or the permission levels.

Again, I'm not sure what you're trying to say. Do you mean that theme uploads should work without setting special ownership on the files? I agree; that's why I filed the bug report. Do you mean that a sysadmin should not set file ownerships to match the security practices that are common to all unix systems running web servers and are recommended by the Wordpress docs? I would have to be really ignorant of security issues in order to agree with that.

WordPress does NOT access the files directly.

Perhaps not, but the bug still exists. I have come across reports of similar bugs that could be attributed to indirect accesses, such as through PHP's getmyuid() function.

WordPress uses FTP to modify the files (Unless WordPress is in a suPHP/SuExec environment, Or you've messed with ownership/permissions),

The behavior I observed is that Wordpress tries installing themes first by directly writing to the filesystem, and secondarily by trying an FTP server. I've seen it install themes without an FTP server running on the host machine, and only fail with FTP-related error messages when the ownership of those two files is not set as I described in my report.

It'd be much appreciated if you'd report the original error you came up against.

I did. This is it. You might want to check out #10898 as well (which I discovered only after a good deal of investigating the original error I came up against).

Look, I spent a few hours diagnosing and reporting this bug because I though I'd do the community a favor, but I'm less inclined to donate my time when I get replies like yours. I'm not a heavy Wordpress user, and I'm not interested in fighting to get someone to believe what I've written, so I don't have much reason to stick around here. My report contains enough information for someone to reproduce the problem. Go for it.

http://www.google.com/search?&q=wordpress%20theme%20%22failed%20to%20connect%20to%20ftp%20server%22

comment:3 in reply to: ↑ 2 @dd326 years ago

Replying to foresto:

Replying to dd32:

Unfortunately both of those resources you've refered to do NOT make reference to the upgrade/install process.

I'm not sure I understand you. Are you trying to say that the two PHP files I mentioned do not contain code that is used in the theme install process? That may be the case, but the problem I described still exists.

Sorry, The resources i referred to were the codex page links.

you should NOT have to change the ownership of the files, or the permission levels.

Again, I'm not sure what you're trying to say. Do you mean that theme uploads should work without setting special ownership on the files? I agree; that's why I filed the bug report. Do you mean that a sysadmin should not set file ownerships to match the security practices that are common to all unix systems running web servers and are recommended by the Wordpress docs? I would have to be really ignorant of security issues in order to agree with that.

What i'm saying, is the default security settings which are used (755 for folders, and 644 for files) are fine, So are defaults of 400 and 700, The Permissions on the underlying filesystem should NOT be changed to allow the upgrades/installs to work, it should work via FTP or selected transport without compromising security. Changing permissions or ownership to world-writable or owned by the web server is what i was getting at that SHOULDNT be done.

WordPress uses FTP to modify the files (Unless WordPress is in a suPHP/SuExec environment, Or you've messed with ownership/permissions),

The behavior I observed is that Wordpress tries installing themes first by directly writing to the filesystem, and secondarily by trying an FTP server. I've seen it install themes without an FTP server running on the host machine, and only fail with FTP-related error messages when the ownership of those two files is not set as I described in my report.

Poor choice of wording on my behalf, It doesnt actually try to write the files, It does however test the writeability of the folder early on when determining which transport to operate with.

It'd be much appreciated if you'd report the original error you came up against.

I did. This is it. You might want to check out #10898 as well (which I discovered only after a good deal of investigating the original error I came up against).

Then thats all you had to say, Generally, When someone contacts me directly, They neglect to mention the error message, and just say it doesnt connect, or copies the generic error you've got fro ma support thread or similar.

My report contains enough information for someone to reproduce the problem. Go for it.

Thats the problem, I cant reproduce it with my servers.

Can you check which filesystem transport you're using? If its using the FTP Extension, try changing it to the FTPSockets library, There has been some reports of the ftp extension being broken on some hosts.

comment:4 @dd326 years ago

Can you check which filesystem transport you're using? If its using the FTP Extension, try changing it to the FTPSockets library, There has been some reports of the ftp extension being broken on some hosts.

Look into the get_filesystem_method() function, and comment out the ftp extension branch for that.

comment:5 @dd325 years ago

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

Closing as worksforme due to no reporter response.

Please re-open with specific server details and failure messages if appropriate.

Note: See TracTickets for help on using tickets.