Remove write access for the process running apache on your blog directory oughta do it.
A blank and read-only .htaccess didn’t work?
HandySolo – thank you for your reply.
I tried a blank .htaccess, but it seems like the mere presence of a .htaccess file causes problem. (The file’s permissions are 666 – I can’t seem to change this; will ask my site administrator to change it to test…)
Unfortunately I have had to as my site administrator set the web root directory with 777 permissions in order to get wordpress backup to work — that unfortunately has the side effect of allowing WP to create .htaccess files!
Is there anything I can configure within wordpress to stop it from creating .htaccess files?
Your web root directory shouldn’t be 777! 755 is just groovy and much much safer.
The backup thing needs to be able to write to one directory under /wp-content/backup-xxxx where the x’s are some random number.
If you have phpmyadmin available from your host cpanel, it’s far better to use it to get db backups than to use a plugin which requires setting any folder 777.
Your host cpanel should allow you to set up a cron job to handle this whole thing for you, safely and securely.
Set the .htaccess up such that the site works properly, then chmod the file to 444.
Yes, that works too – sometimes. The setup I have with my host, 444 does not work, it must be 644 in order to enable even accessing permalinks.
In a shared environment, setting 644 (for files) and 755 (for directories), while not as insecure as 666 and 777, is a bad idea. You should be using 640 and 750 instead, otherwise you’re opening up security holes.
Of course, I’m assuming that your account is in the Apache user group, which it should be.
To me, pizdin_dim? If so, I’ll check to see if that’s possible, thanks.
If you’re hosted very few hosts allow going down to 640. You’ll get “permission denied” errors.
Yup, that’s true, samboll. My techie just stated that it’s a “host-privilege” setting.
Now, I have to say my host is MORE than accomodating with me, so I will inquire further.
“You’ll get ‘permission denied’ errors.”
That will only happen if your account is allocated to a group other than Apache. I wasn’t aware that it’s common for host providers to actually do that but it seems they obviously they do.
Why would you set things up so that server processes acting on behalf of anonymous clients get group permissions?
Generally speaking, the Apache server really should not be in the same user group as the files it’s reading and serving to the world. That’s sort of the whole point of having world permissions, eh?
Hi Thank you for everyone’s help. I have now removed 777 permissions and I asked my system administrator to grant me rights to use chmod. And it appears wp-backup is still working.
And actually, I maanged to get a blank .htaccess that works — the problem previously was my blank .htaccess had some Windows non-breaking character or something so then it wasn’t quite blank. Using a *proper* text editor (well, Visual Web Developer 2005 Express Edition) solved it.
Still, it would have been nice if there was some config file that allowed me to solve this problem.
Thank you!
“Generally speaking, the Apache server really should not be in the same user group as the files it’s reading and serving to the world.”
You obviously know something I don’t. Exactly why shouldn’t it?
You obviously know something I don’t. Exactly why shouldn’t it?
Well, mainly for security reasons. If your server is running as the same group as the user, then it has whatever permissions you’ve given that group. Any hole in a script or CGI program which allows remote code execution means that the program can get those group privileges.
It’s just a matter of limiting the capabilities at every stage. Your server, if it does anything worth doing, is going to be running code that your users put into their web directories. Anonymous clients are going to be causing this to happen. If one of your users puts code out there with a hole in it, and somebody exploits it, you still can limit their access. Don’t give them group rights. Keep them in the lowest privilege level (world). If it turns out that you absolutely *need* a CGI program to get higher privs, and you’re convinced it’s safe, you can set the setuid or even setguid flag on that specific code alone, thus letting that program only run as who it needs to run as. Or you can run it under sudo or some such thing.
Fact is that very little code requires this sort of thing, and at any given point, you should strive to keep the user/group/world concepts and set things up to keep that separation. If the whole world (aka untrusted users) can cause it to happen, then it should be happening with world privs only.
It’s just a general good security concept. There’s no specific reason behind it.
