[wp-trac] [WordPress Trac] #10205: getmyuid() called instead of posix_getuid() in get_filesystem_method() (wp-admin/includes/file.php)

[WordPress Trac]

#10205: getmyuid() called instead of posix_getuid() in get_filesystem_method() (wp-
admin/includes/file.php)
------------------------------------+---------------------------------------
 Reporter:  pgl                     |        Owner:  dd32           
     Type:  defect (bug)            |       Status:  reopened       
 Priority:  normal                  |    Milestone:  Awaiting Review
Component:  Filesystem              |      Version:  2.8            
 Severity:  normal                  |   Resolution:                 
 Keywords:  has-patch dev-feedback  |  
------------------------------------+---------------------------------------

Comment(by joelhardi):

 > See also #14753. dd32's reply there is why I am pulling this off 3.1. He
 can go into more detail here I'm sure.

 I fully understand the reasoning behind why things currently work the way
 they do, I just think that it's a band-aid that has side effects that are
 worse than the problem it's trying to address. I'd also argue that problem
 is overblown at best and certainly doesn't exist at most large shared
 hosting companies who have configured UNIX permissions correctly.

 Forcing users to chown their !WordPress scripts to the webserver user is a
 sysadmin headache, and a security problem -- you're giving PHP scripts the
 ability to write to themselves and potentially do code injection. The
 [http://blog.arithm.com/2010/04/03/get-wordpress-to-stop-asking-for-
 connection-information-when-upgrading-plugins/ workaround] is ugly.
 Defining FS_METHOD is better, but to me it's still a hack. I'd be willing
 to consider it an "acceptable" hack only if the UI here weren't so opaque
 (how are users supposed to know they have to add this constant?).

 I'll go over why I think the getmyuid('options.php') check needs to go ...

 First, this isn't consistent with how the rest of !WordPress works. i.e.
 when you upload an image or other media, !WordPress only checks to see
 whether it can write to the filesystem. That's it. If this were a real
 problem, then unsophisticated users not being able to move or delete their
 webserver user-owned image files would be a much bigger one. It would be
 one thing if !WordPress did this getmyuid() check whenever it creates any
 file, but in fact this extra requirement (that all !WordPress files have
 to be owned by the same user, who also must be the webserver user) is only
 being enforced here.

 Big shared hosting companies don't run Apache mod_php with webserver user
 privs any more, exactly because of these sorts of user support file
 ownership issues. They've learned it's easier to use suEXEC or run PHP via
 cgi and just have everything in a customer's user dir owned by that user.
 Each customer has their own user/group. So, the getmyuid() check solves a
 problem that I would argue doesn't really exist.

 Hosts have already addressed this sort of issue where it should be
 addressed (on the sysadmin side) -- I'd use the analogy of OSI layers here
 and argue that at !WordPress' level (PHP scripting), it shouldn't be
 forcing people to chown or chgrp their files to any specific user or
 group. It should be totally agnostic to UNIX users/groups and just care
 whether it can write to the files or not.

 Finally, !WordPress can ''always'' be used to delete plugins it has
 installed or images it has uploaded ... the underlying issue
 (unsophisticated user says "I can't delete my own files!") can also be
 solved by just having them click "delete" in !WordPress.

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