[wp-trac] [WordPress Trac] #10424: change get_filesystem_method()'s code for direct to reflect actual purpose

[WordPress Trac]

#10424: change get_filesystem_method()'s code for direct to reflect actual purpose
--------------------------+-------------------------------------------------
 Reporter:  dd32          |       Owner:  dd32          
     Type:  defect (bug)  |      Status:  new           
 Priority:  normal        |   Milestone:  Future Release
Component:  Filesystem    |     Version:  2.9           
 Severity:  normal        |    Keywords:  needs-patch   
--------------------------+-------------------------------------------------

Comment(by dd32):

 > Could you link to an explanation that provides the reasoning?

 I dont have the explanation handy, However, I will explain it:
  * Under most shared hosting environments apache will be running as
 apache:apache (user:group)
  * Under most shared hosting environments, The users files will be owned
 by <username> and have a group of either <username> or <apache> (To allow
 apache access to the files)
  * Under *some* shared hosting environments, apache will be able to
 read/write the users files, even when the Apache Process is not running
 PHP as the same user that owns the files.

  * If apache creates a file in a users folder (is_writable()) it'll often
 be owned by apache:apache, This is the reason that a lot of users will
 have to chmod their uploads folder to 777 or 775
  * If the folder is NOT chmod'd to 777/775 AND PHP/Apache is executing the
 code as a user other than who owns the files, Often results in files being
 created in the users folder which are not owned, or modifyable by the user
 via FTP
    * This often results in files which are undeletable, other than via
 Cpanel or directly by the host
    * Also results in the files not counting towards the users quota in
 some cases
  * Having the folders chmod'd to 777/775 allows for the user to be able to
 modify the files in that folder via FTP. (It also allows any other user on
 the box(777) or any other user in that group(775) to modify the files in
 that folder)
   * Yes, This is an unsecure environment for a hoster to be running,
 However it is often common.
     * Quite often, Apache(and PHP) can read ANY file in other users
 folders due to this, The setup is a bad one, but is much more common
 amongst el-cheapo hosts around the world than one would prefer.
   * Some european countries seem to have much less of this type of setup
 however, And seem to have configurations under which the direct access
 method would work, however is currently failing.

 However:
  * If apache is running as apache:apache
  * The files are owned by <username>:<username>
  * Apache executes PHP as the owner of the files (suPHP / ExecPHP) as
 <username>:<username>
 THEN
  * PHP can read/write the files in the users folder as if they were its
 own (As they are)
  * The user accessing via FTP can read/write the files as if they are
 their own (As they are)

 That is the entire reason for FTP, In the event that writing files
 directly to the hard drive via PHP causes the files not to be owned by the
 user, or potentially not modifyable by the user, there is a fallback
 option available.

 I am not 100% sure why i originally used getmyuid() & family, Perhaps it
 was because it worked, It might not have been the best choice however.

 See also: Ticket #12201 getmyuid() is disabled - workaround

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