[wp-trac] [WordPress Trac] #10895: theme upload / delete fails due to update.php / themes.php ownerhip

[WordPress Trac]

#10895: theme upload / delete fails due to update.php / themes.php ownerhip
-------------------------------+--------------------------------------------
 Reporter:  foresto            |        Type:  defect (bug)   
   Status:  new                |    Priority:  normal         
Milestone:  Unassigned         |   Component:  Upgrade/Install
  Version:                     |    Severity:  normal         
 Keywords:  reporter-feedback  |  
-------------------------------+--------------------------------------------

Comment(by dd32):

 Replying to [comment:2 foresto]:
 > Replying to [comment:1 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.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10895#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software