Posted 4 months ago #
Hey Donncha,
I was thinking that there should be one more warning message that should appear during the installation of wp-supercache.
During the install process the last step asks you to make wp-content writable at 777. I think once this is complete it would be advisable to have a message based on checking whether wp-content has been returned to 755 after install.
Just for safety's sake!
Posted 4 months ago #
Of course, I neglected to consider that this makes it impossible to turn off super cache (or can this change be made by just having wp-content/wp-cache-config.php set at 666?).
I just feel a little apprehensive having any folders set at 777 I guess :)
Good idea. I just added a check into trunk for that. You can still change the config file, as long as the file itself is writeable!
Posted 4 months ago #
Deadly, nice one :)
Posted 4 months ago #
This change doesn't seem to be right. With the new version I'm getting a bogus warning telling me to change wp-content to mode 755, even though it's already mode 755.
This appears to be happening because the code does:
if( is_writable( ABSPATH . 'wp-content/' ) )
... then tells people to chmod 755 if so.
However, decent hosting companies run PHP scripts under the individual user's unique UID in the first place, meaning that it's perfectly possible for a mode 755 directory to be writable by the script. In other words, is_writable() doesn't necessarily mean the directory has been left as mode 777.
If you're trying to check whether the directory has been left as world-writable on a lame hosting company that uses shared uids (and where leaving it world-writable would therefore be a security risk), which is a good idea, it should probably do something like this instead (untested):
if( fileperms( ABSPATH . 'wp-content/' ) & 0x0022 )
That will tell you if it's world- or group-writable, I think.
Thanks for the great plugin!
tigertech - try the version of the plugin in trunk. You can get it at http://svn.wp-plugins.org/wp-super-cache/trunk/ - does that work?
The current version, 0.6.5, doesn't have the modified code I mentioned above.
We'll just have to disagree about "decent hosting companies run PHP scripts under the individual user's unique UID in the first place". That's a huge security risk IMO.
Posted 4 months ago #
The version in trunk fixes it, thanks.
Regarding your comment about running PHP scripts under individual UIDs being a security risk: I think there might be a misunderstanding, because it's actually far more secure than the alternative.
It's definitely not secure to run the scripts from several different customers under one UID and rely on something like PHP's safe mode to keep customers separate.
Safe mode, by the admission of PHP's own developers, was a bad design decision ("It is architecturally incorrect to try to solve this problem at the PHP level") that hasn't worked reliably over the years (there have been a constant stream of PHP security vulnerabilities related to it). Safe mode has actually been removed from PHP 6, and the PHP developers are telling people to do it properly with lower-level permissions in the future. Hosting companies will have no choice but to switch if they want to support PHP 6.
Relying on the underlying operating system permissions to keep UIDs separate is inherently more secure, because that code is far better tested and localized. If customer 1000 can only run PHP (and other) scripts under his own unique UID 1000, and that UID cannot access the files and directories of separate customer/UID 1001 due to Unix permissions, that guarantees that one customer can't read (let alone write) the private files of another customer.
PHP's safe mode and similar "shared UID" solutions try to accomplish the same thing, but have never worked reliably enough to be truly considered secure (even if the hosting company blocks all other script and shell access, which most don't).
Great, glad it worked. Must release a new version soon!
Posted 4 months ago #
I also thought it might be a good idea that if someone makes their .htaccess writeable (in order to have it updated by wp-super-cache) that once the update has gone through there should be a warning message telling that person to return their .htaccess file to 644.
Posted 1 month ago #
I have an ugly permission problem too http://wordpress.org/support/topic/209157
Could it be related?
You must log in to post.
