fhsm

I’ve really RTFC on this one and think the WP_Filesystem object shouldn’t be beyond my comprehension. So at frustration overload and decided to pull apart the core code, when I did so I found something a bit odd. In file.php on line 842 getmyuid() is called if ( getmyuid() == @fileowner($temp_file_name) ).

If you have a look at bozo_z_clown at yahoo dot com‘s comment on php.net (s)he will draw your attention to how strange this functions behavior is. The docs (“Gets PHP script owner’s UID”) should put more attention on script owner’s UID. It’s not the UID of the running process, it’s actually the UID of the file that the process is interpreting at present. In other words if the running process might loads N files (require/include etc) in responding to a single hit the value of getmyuid() could be N different ints depending on where it’s called.

To my mind the more useful function is posix_getuid which returns the actual running process and results in the expected (perhaps correct?) behavior on my server when swapped for getuid at line 842.

This feels like a bug to me. I’m not sure if the intended security benefits are really recognized, if it’s that big of a problem (the file system should restrict application code not the other way around), and if this isn’t a case of tossing the baby with the bathwater.

Turns out I’m not the only person who thinks this is a bug, bug, bug. Thanks to joelhardi, after 17 mo and an attempt to close the bug, a patch is awaiting review.

On the plus side I learned in my first trip into substantive wp dev that the bug tracker isn’t all that well indexed by google; on the downside, I found the bug tracker.

Thanks for the reply. I’ve actually spent a good deal of time looking at the code you’ve linked (I linked in the op).

What advantage does the function you provided have over just setting FS_METHOD constant to ‘direct’?

The WP_Filesystem accepts args & context and passes them on to get_filesystem_method. It looks like $args get passed to the ‘driver’ classes for things like login, pw etc but $context is used as a file system path to test ownership etc as you mentioned.

My www root is owned by & in the root group; however, I’ve chgrp-ed & chown-ed uploads/ & blogs.dir/ to apache. As a result on my server plugin’s aren’t upgradable with direct access (b/c WP is in a different group, different UID and lacks FS permissions). When I do the override with FS_METHOD the resulting files in uploads/ & blogs.dir/ both have the expected ownership, group & permissions. All of which leaves me to believe something is going wrong with the detection.

If get_filesystem_method() does its write-testing in WP_CONTENT_DIR I’d expect it to fail, so it seems like this is a good use for $context… if I could figure out how to use it.

Sorry I double posted somehow please see use: https://www.ads-software.com/support/topic/how-to-initialize-wp_filesystem-object

Can a mod delete this one or someone tell me how to delete this one to avoid confusion.

Thx.

Thanks for the tips.

I’m working w/ a multisite network that runs over SSL. Moving it to localhost isn’t going to be as easy as the dev/stage/deploy cycle of a drupal site. I’ve just had to set up a DNS server on my LAN. Hard to believe that’s really the easiest way around the problem but I think it is.

No problem with a clean install on this stack.

I can even import wp-config and use the defined variables to establish a connection with the database manually.

The error is clearly miss-information.

How do you migrate a multisite network from production to dev and back?

Yes and no. No I didn’t do it from the web UI before dumping (i don’t want to go messing around with a site that is in active use). Yes did a find and replace on the dump before pushing to the local server.