Plugin Author
AITpro
(@aitpro)
Did the CHMOD function actually unlock the .htaccess files and update them?
Looks like it was not allowed so that would unfortunately mean that you would have to manually update the .htaccess files or temporarily change file permissions to allow the auto-update to complete successfully.
The only thing that changed in the root .htaccess file is that ErrorDocument 401 default was added, which prevents 404 errors from occuring if the site has any password protected directories.
ErrorDocument 400 /wp-content/plugins/bulletproof-security/400.php
ErrorDocument 401 default
ErrorDocument 403 /wp-content/plugins/bulletproof-security/403.php
ErrorDocument 404 /404.php
You assume the webserver is also the owner of the file, and thus is allowed to chmod() the file.
In fact, all the webserver needs is write access to the file.
Consider this:
-rw-rw-r-- user website .htaccess
If the webserver is in the website group, all is good, even if the webserver is not allowed to chmod() the file.
js.
Plugin Author
AITpro
(@aitpro)
Sounds good to me. BPS does not do anything with CHOWN since it would not do anything anyway from the Dashboard. Thanks.
The chmod() error still exists though. You can’t chmod() if you don’t own the file. 😉
js.
Plugin Author
AITpro
(@aitpro)
Yep, I updated my comment above. I have experimented with CHOWN and it is just ignored by the Server.
Plugin Author
AITpro
(@aitpro)
I have been meaning to look at how WordPress itself handles this in class-wp-filesystem-direct.php and WP is doing this successfully so I will look into hooking into this and see if this works.
/**
* Changes file owner
*
* @param string $file Path to the file.
* @param mixed $owner A user name or number.
* @param bool $recursive (optional) If set True changes file owner recursively. Defaults to False.
* @return bool Returns true on success or false on failure.
*/
function chown($file, $owner, $recursive = false) {
if ( ! $this->exists($file) )
return false;
if ( ! $recursive )
return @chown($file, $owner);
if ( ! $this->is_dir($file) )
return @chown($file, $owner);
//Is a directory, and we want recursive
$filelist = $this->dirlist($file);
foreach ($filelist as $filename) {
$this->chown($file . '/' . $filename, $owner, $recursive);
}
return true;
}
Plugin Author
AITpro
(@aitpro)
Argh what a pain in the neck. It is no wonder I keep getting discouraged and putting this issue on the back burner. The more I look at this for DSO and non-suPHP Server configs the more I don’t want to consider all the massive amount of coding work this would take to work for every possible Server config scenario. sigh. Eventually a streamlined method will be figured out, but at this point trying to account for every possible scenario for DSO and non-suPHP Server configs would be a considerable pain.
Plugin Author
AITpro
(@aitpro)
This is going to be a long term eventual addition to BPS, but at this time this has a much lower priority (99% of users do not encounter this issue/problem vs 1% of users who do encounter this issue/problem) and is once again being pushed back. Resolving for now as an eventual addition to BPS when all other top priorities are completed.
Why not just use is_writable() on the .htaccess, and if it fails, display an error so the user can adjust file/dir owners/perms?
The chmod() really isn’t the way to go since you have to be the owner to change file perms. This may be the case in most instances, but not for more customized WP installs (for example, one user account may upload the plugin (or many users), and the web server user ID might be different (“apache” or “httpd” for example) – the web server cannot chmod() files owned by other users).
js.
Plugin Author
AITpro
(@aitpro)
A file open and write check already occurs on the Edit/Upload/Download page, but I absolutely agree that an additional pop alert/displayed message should be added.
File Open and Write test successful! The secure.htaccess file is writable.
File Open and Write test successful! The default.htaccess file is writable.
File Open and Write test successful! The maintenance.htaccess file is writable.
File Open and Write test successful! The wpadmin-secure.htaccess file is writable.
File Open and Write test successful! Your currently active Plugins htaccess file is writable.
File Open and Write test successful! Your currently active Uploads htaccess file is writable.
Your root htaccess file is Locked with Read Only Permissions.
Use the Lock and Unlock buttons below to Lock or Unlock your root htaccess file for editing.
File Open and Write test successful! Your currently active wp-admin htaccess file is writable.
chmod is not really the issue. 99% of folks have Servers that are CGI suPHP. 1% of folks fall into the category where chown would need to be used to temporarily change Ownership in order to allow writing. What keeps happening is that priorities on our list keep bumping this development back because of the fact that this only affects 1% of users.
We are close to completing a top goal/priority. Once that is completed then DSO/non suPHP coding will be the next focus.
