[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:          
Component:  Filesystem                                                                          |      Version:  2.8     
 Severity:  normal                                                                              |   Resolution:          
 Keywords:  uid, filesystem method, file.php, posix_getuid, getmyuid, direct, install, upgrade  |  
------------------------------------------------------------------------------------------------+
Changes (by joelhardi):

 * cc: joel@… (added)
  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 Forgive me for reopening an old bug on an issue that has many duplicate
 bugs. But, I have a patch.

 After banging my head about this bug (constantly getting the FTP
 "Connection Information" box) no matter what I {{{chown}}} or {{{chmod}}}
 directories to, I now understand the problem. And, I see that there is the
 {{{FS_METHOD}}} constant that I can define to work around it. That's good.

 But, I still think the default behavior can be improved. As I understand
 it, the issues are these:

  1. WordPress is going to write files as the webserver/cgi process, i.e.
 www. This is {{{posix_getuid()}}}
  2. The PHP files themselves (i.e. {{{wp-admin/update.php}}} for updating
 a plugin) could be owned by anyone, as long as they're readable by the
 webserver. Their owner is {{{getmyuid()}}}. Generally, you do '''not'''
 want them to be owned by the webserver/cgi process for security reasons,
 unless you're auto-upgrading WordPress.
  3. WordPress will only let you add or update a plugin if {{{getmyuid()}}}
 and {{{posix_getuid()}}} are the same (i.e. if ''everything'' is owned by
 www or a suEXEC Apache).

 So, for instance in my case, all the files are owned by {{{johndoe}}},
 except for a couple of directories like {{{wp-content/uploads}}} that I
 {{{chown}}} to {{{www}}} so that WordPress can put images etc. there.

 If I try to upload a plugin, it fails because getmyuid() returns johndoe,
 but the webserver creates files as www. The actual fix would be for me to
 chmod wp-admin/update.php (I think) to www so that getmyuid() will return
 www. The problems are: I don't want to change my file ownerships this way,
 it's a security problem; this is very obscure and most people can't be
 tracing code and chowning files every time WordPress refuses to do
 something; and WordPress doesn't tell me any of this, it just presents
 this box asking for FTP credentials that made no sense to me at all, which
 looks like a mistake. FTP??? I don't even have an FTP daemon running and
 never told WordPress anything about FTP.

 The first time I had saw this FTP box pop up was when I was trying to
 ''delete'' a plugin (testing to see if my uninstall hook worked), which
 made the FTP box seem even more bizarre.

 I understand the file deletion problem on shared hosts -- you don't want
 WordPress to create files that users then can't delete. Then, these users
 go "WordPress is broken!" and it creates many support headaches (of
 course, these users ''can'' always use WordPress to delete these files as
 the www user). Fair enough. Obviously, posix_getuid() is also not
 available on Windows.

 Personally, I think all WordPress should be doing is "Can I write to the
 filesystem? OK, then I will write to the filesystem," like it does when
 you upload an image. I should be able to run my daemons and chown my files
 the way I want! I would point out that WordPress is already creating files
 owned by the webserver/cgi user (uploaded images and other media), and
 argue that it's inevitable. The thing to do is not allow it in one case
 and silently block it in another, but to gently guide the user around
 these issues. But, I understand that in this case (maybe because people
 upgrade plugins more often than they delete images) someone had a
 different design goal.

 I don't suggest there's a way to magically solve all these issues, only
 that there's room for improvement. With that said, I'd suggest one of:
  1. My patch. It just checks whether {{{posix_getuid()}}} is available
 and, if so, allows install to proceed if either {{{getmyuid()}}} or
 {{{posix_getuid()}}} matches the temp file owner. To me this is normal,
 the user is attempting a direct file upload, so allow it to proceed if
 there's no reason why it shouldn't. Unlike the other patches I've seen,
 it's not swapping out getmyuid for posix_getuid, it's allowing either one
 to match.
  2. An "Are you sure?" confirmation step or informational message after
 activation. i.e. if {{{getmyuid()}}} and {{{posix_getuid()}}} do not
 match, say "Uploaded files will be/have been created as the user [uid], so
 to delete them later you will have to use the WordPress uninstall feature
 (unless your FTP or shell user account has write access to [uid]'s
 files)."
  3. Minimally, an error message explaining the situation and reason for
 the FTP box. As I said, just popping up the "FTP Connections" box made no
 sense to me, and judging by Google I'm not the only one. And I don't have
 or want FTP, so it's a dead end. Something like:

 {{{
 Sorry, you cannot upload files directly to WordPress because this script
 (update.php) is owned by [uid], but new files created by WordPress are
 owned by [uid]. To fix this problem you can do either of the following:

  * Allow WordPress to create files as [uid] by defining FS_METHOD in
    wp-config. (with link to wiki page explaining "direct" etc.)

  * Use FTP to upload the files to WordPress (with link)
 }}}

 I'm happy to contribute code toward whatever solution.

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