PREVENT wordpress from creating .htaccess file

hm, tricky. Only thing I can think of is writing a plugin that turns the global $is_apache to FALSE any time an .htaccess write would take place (maybe checking for $_POST submissions and comparing $_SERVER['REQUEST_URI'] with something. This will short-circuit the .htaccess write, as it won’t attempt it for non-apache systems. I can’t promise that this won’t break something else, however.

Otto,

Perhaps we’re getting off topic, but … I thought I understood the Unix file permission system but what you’re telling me contravines what I know.

“If your server is running as the same group as the user, then it has whatever permissions you’ve given that group.”

Right, which is always going to be read permissions (chmod=6 for files and chmod=5 for dirs). So how is that different to having the webserver as “others”? The webserver still requires exactly the same permissions (chmod=6 for files and chmod=5 for dirs). Where is the difference?

“Keep them in the lowest privilege level (world).”

I don’t understand just how “others” (world) is actually a “lowest privilege level”, as you put it. I don’t see any relationship between “others” and any implied privilege level. As far as I was aware, there is no hierarchy in file permissions. There is simply permissions for the user, the group the user is in and everyone else. Obviously setting files to be writable by the group is exactly the same as setting them to be writable by everyone else.

Say my account name is “mysite.com” and my host puts me into a group called “users” (chown=mysite.com:users). Let’s also say that the webserver username is “httpd”. If I chmod a file to “640” that means I can read and write it, other people in the group “users” can only read it and the webserver can do nothing, so the correct chmod should actually be “644” in this instance, right?

Say my account name is “mysite.com” and my host puts me into a group called “httpd” (chown=mysite.com:httpd). Let’s also say that the webserver username is “httpd”. If I chmod a file to “640” that means I can read and write it, other people in the group “httpd” (which includes the webserver) can only read it, right?

In this instance, how are the two scenarios different?

Right, which is always going to be read permissions (chmod=6 for files and chmod=5 for dirs). So how is that different to having the webserver as “others”? The webserver still requires exactly the same permissions (chmod=6 for files and chmod=5 for dirs). Where is the difference?

Actually, Read = 4, for both directories and files. Write = 2, Execute = 1. Add them together to combine permissions. Read+Write = 6. RWX = 7. RX = 5. That sort of thing.

And it’s not a matter of permissions for what the webserver can read, it’s a matter of what code the webserver can run. Websites aren’t just things you read anymore, they’re executable code.

By putting your files in the httpd group and having the webserver process in that same group, then you’re giving those group permissions to any random shmuck who happens to use your website, which is something you might not want to do.

Consider the case where my users are in group “users”, and the webserver is not (say it’s httpd/httpd). Now, one of my users loads some PHP or other form of code onto his website directory which, as it turns out, is insecure. So somebody comes along and gets their own process to run on my server using his hole.

What permissions does this process now have? In my scenario, it’s running as a process with user/group of httpd. The httpd group is not the users group, and so that process does not get group permissions for the users files. It only gets the world permissions. If those permissions are 644, then yes, there’s no difference, but what if some of my users assigned, say, 664 instead? Suddenly we have a bit of a difference.

The difference is conceptual. Untrusted code should not be running as something which will potentially have damaging permissions. The user/group/world difference should be maintained wherever possible.

The webserver is taking input from the entire world and passing that input to untrusted code. If the result of this is that the now running code gets group permissions for darn near *anything* on that server, you’re looking at a potential headache situation.

I don’t understand just how “others” (world) is actually a “lowest privilege level”, as you put it. I don’t see any relationship between “others” and any implied privilege level. As far as I was aware, there is no hierarchy in file permissions. There is simply permissions for the user, the group the user is in and everyone else.

All processes have a user and a group. If their user matches the file’s user, they get user permissions. If not, then the group is checked for a match. Again, if not, then the world permissions are used. That’s the hierarchy aspect of it, a process gets the highest level of permissions that it happens to match. Now, the permissions themselves are separate. I mean, yes, you can assign 604 if you want, letting everybody *except* those in your group read the file, although that would be a bit silly.

Obviously setting files to be writable by the group is exactly the same as setting them to be writable by everyone else.

No. It’s not. That’s my whole point.

chmod XYZ file.
X = User permissions.
Y = Group permissions.
Z = World permissions.

Group and world are separate. And you want to make sure that running code which is possibly coming *from* the world should never be accessing files based on permissions other than the world.

Say my account name is “mysite.com” and my host puts me into a group called “httpd” (chown=mysite.com:httpd). Let’s also say that the webserver username is “httpd”. If I chmod a file to “640” that means I can read and write it, other people in the group “httpd” (which includes the webserver) can only read it, right?

Right. So, now how do you differentiate between other users/programs on your server and the rest of world (via the webserver)? What if I have a cron job that runs every day to clean up my site or perform some kind of maintainance? I want it to be able to access some of my files, but not all of them, because I don’t know much about this job (say my host provides it, or it’s code I haven’t examined carefully). It needs write access to some of those files, but I don’t want it to actually run as “me” because I don’t trust it. So I set it to run as my group instead. Oops, those files are 640, better set them to 660. Oops! Now I’ve given the entire world (via the webserver) write permissions on my files. Bummer. If my webserver only ran with a different user and group, I could set those files 664 and be perfectly safe while having everything working.

There’s three file permission levels for a reason. Bypassing one of them by defining world as equal to group is silly.

Thanks for taking the time with a lengthy reply, but…

“Actually, Read = 4, for both directories and files.”

Yes, I understand that. That’s what I was implying when I said “chmod=5 for dirs”. Read and execute are both required for a directory in order to read files in it.

“And it’s not a matter of permissions for what the webserver can read, it’s a matter of what code the webserver can run. Websites aren’t just things you read anymore, they’re executable code.”

I agree, but for files accessed over the web, that permission is given by allowing “read” access. So, for the webserver to execute the PHP code, all it needs is read permission. Unless we’re talking CGI, which I’m not.

“If those permissions are 644, then yes, there’s no difference, but what if some of my users assigned, say, 664 instead? Suddenly we have a bit of a difference.”

I don’t understand what you mean. In your example, setting 664 for that PHP script still only means that the webserver can only read, not write that file. Yes, whoever is in the group “users” can both read and write that file but the webserver cannot. True? Futhermore, setting 664 for that file would be foolish because it will enable all other users who happen to be in the group “users” to write that file, which is exactly what you don’t want. True?

“The webserver is taking input from the entire world and passing that input to untrusted code.”

Yes but what does that have to do with whether the webserver is “others” and you make the script “mysite.com:users” and “644” or whether the script is “mysite.com:httpd” and “640”. Either way, the webserver gets to read the script and hand it over for execution. In any case, using “644” in the former is a bad thing anyway, isn’t it? Why would you want to give read permission to everyone in the group “users” as well as giving read permission to “httpd”? The correct setting for the former should really be “604”, no? What possible reason could we have to allow every user of the system to read files of other users who are in the group “users”?

“There’s three file permission levels for a reason. Bypassing one of them by defining world as equal to group is silly.”

I think we’re saying the same thing. I never advocated that “defining world as equal to group” is correct. If that’s how it was understood, then I failed to express myself succinctly.

Let me use a specific example for web scripts. Owner is “mysite.com”, group is “users” and the webserver is “httpd” and both of these will work as intended:

1. -rw-r--r-- 1 mysite.com users Feb 03 15:36 script.php
2. -rw-r----- 1 mysite.com httpd Feb 03 15:36 script.php

How are the two different? In both cases, the page gets to be read by the webserver, no problem. The former also grants read permission to everyone in the group “users”, which the latter doesn’t. Therefore, the latter is better for websites, isn’t it? With the former, I see a big security problem. What’s to stop some other user, who is also in the group “users”, simply doing this via SSH:

cat /home/users/mysite.com/www/html/wp/wp-settings.php

They now get to see all the sensitive stuff I didn’t want them to see. The former should really be:

1. -rw----r-- 1 mysite.com users Feb 03 15:36 script.php

It still makes no difference to the webserver but the script is more secure.

So, for the webserver to execute the PHP code, all it needs is read permission.

Then you configured the webserver wrong. IMO, of course.

In your example, setting 664 for that PHP script still only means that the webserver can only read, not write that file. Yes, whoever is in the group “users” can both read and write that file but the webserver cannot. True?

True, however in *your* configuration, where the webserver has group rights, it can read and write a 664 file as well. My point is that it should not be able to do so.

I never advocated that “defining world as equal to group” is correct. If that’s how it was understood, then I failed to express myself succinctly.

No, you’ve expressed yourself very well, but you still fail to understand the ramifications of what you’re saying.

If the webserver is running with group permissions, then world = group, because the webserver really is *the world*, as in anybody in the world can access it. That’s what a webserver *does*. Thus you want it to run in a way that it uses world permissions when accessing served files. See?

Let me use a specific example for web scripts. Owner is “mysite.com”, group is “users” and the webserver is “httpd” and both of these will work as intended:
1. -rw-r–r– 1 mysite.com users Feb 03 15:36 script.php
2. -rw-r—– 1 mysite.com httpd Feb 03 15:36 script.php
How are the two different?

Well, for one thing, you changed the group on the files. Why are you doing that? You’ve never mentioned chgrp one time in this thread.

I’m talking about changing permissions and what group the webserver PROCESS runs in. Not about changing file groups.

Therefore, the latter is better for websites, isn’t it?

Possibly, if you’re still in the 90’s. ??

Nowadays they tend to use virtual servers for shared hosting of such things, not separated directory structures on a user level. At least, not where they also give shell access.

But I never mentioned changing the groups of the files. That’s not what I’m talking about *at all*.

“I’m talking about changing permissions and what group the webserver PROCESS runs in.”

Why didn’t you say so before? Well, guess what? I’m talking about file groups. So, now that you understand what I’m saying, then you’re plainly wrong when you say this:

“No, you’ve expressed yourself very well, but you still fail to understand the ramifications of what you’re saying.”

It appears you’ve jumped the gun here, otto. If, as you say, I expressed myself very well, the problem could be with you?

“You’ve never mentioned chgrp one time in this thread.”

Why was there a need to when I clearly explained the permissions using chmod?

“Nowadays they tend to use virtual servers for shared hosting of such things, not separated directory structures on a user level.”

It’s exactly the same thing from a file system point of view: the virtual domain name IS the username.

“If the webserver is running with group permissions, then world = group, because the webserver really is *the world*, as in anybody in the world can access it.”

The webserver is just another user on the system, it has nothing to do with the “world”, as you like to put it. Funny choice of a word anyway: it’s actually called “others”.

It’s interesting that you chose not to reply to the huge security issue I mentioned with my “cat” example above.

Y’know guys, what you’re saying is IMPORTANT. So how about NOT sniping at each other. How about doing some basic “defining”, and then making the REALLY IMPORTANT POINTS.

“Mine’s bigger than yours” doesn’t help the rest of us.

I’ll try and make it as simple as possible but no simpler. From my experience, this is typical in a shared hosting environment:

• Your ISP’s webserver is configured to use the username of “httpd” and a groupname of “httpd”.
• You are the owner of a domain called “mysite.com”.
• Your ISP creates an account for you and your “home” directory is “/home/users/mysite.com/www/html/”.
• Your username becomes “mysite.com” and your groupname becomes “users”.
• You “chmod” your files to “644” and directories to “755”.

Listing the contents of your home directory, should show something like this:

-rw-r--r-- mysite.com users 5481 Jun 06 17:22 wp-settings.php

As far as I’m concerned, this is insecure because an owner of a different domain will have their account setup in exactly the same way as you and will therefore have read access to the sensitive information in your “wp-settings.php” file, using nothing more than an SSH client.

What I’m arguing here is that the following should happen instead:

• Your ISP’s webserver is configured to use the username of “httpd” and a groupname of “httpd”.
• You are the owner of a domain called “mysite.com”.
• Your ISP creates an account for you and your “home” directory is “/home/users/mysite.com/www/html/”.
• Your username becomes “mysite.com” and your groupname becomes “httpd”.
• You “chmod” your files to “640” and directories to “750”.

Listing the contents of your home directory, should show something like this:

-rw-r----- mysite.com httpd 5481 Jun 06 17:22 wp-settings.php

The difference between the two? From the webservers (and therefore web-access) point of view: nothing, in both cases the files only have the read permission set. From the users (humans who own the accounts) point of view: lots, the latter is more secure because people can’t read each others files.

I have seen both methods being used by hosting providers. While there is no doubt in my mind which is the better method, I’m happy to accept the fact that some people will simply not consider it important enough an issue that other people can read their files, whether they contain sensitive data or not.

Listing the contents of your home directory, should show something like this:
-rw-r—– mysite.com httpd 5481 Jun 06 17:22 wp-settings.php

And thus you ensure that when any one of your users sites gets hacked due to an insecure script, the resulting running program has access to all of your web users files instead of just some of them. Good plan.

People expect group permissions to apply to a limited group, and will set those permissions accordingly. What people don’t expect is for publically accessible services to run untrusted processes that will have those group permissions as well.

And your security reasoning here is weak, at best. I can’t read other users files? Hardly. I upload a simple PHP script which opens those users files and spits them out to the webpage. I then access it from the web. Voila, I have read those users files.

Yes, by changing the group on those files, you’ve taken permissions away from other users on that server, but what you’re not seeing is that, at the same time, you’re basically giving group permissions to everybody else in the world, via the webserver.

“And thus you ensure that when any one of your users sites gets hacked due to an insecure script, the resulting running program has access to all of your web users files instead of just some of them. Good plan.”

Good plan, indeed. In terms of WP, the only file that you don’t want anyone else to read is “wp-settings.php”. Irrespective whether they’re reading it with a browser or SSH. By allowing “wp-settings.php” to be readable by others, you allow full access to all your precious data in the database.

“And your security reasoning here is weak, at best. I can’t read other users files? Hardly. I upload a simple PHP script which opens those users files and spits them out to the webpage. I then access it from the web. Voila, I have read those users files.”

See above about “wp-settings.php” being the only important file to protect.

“Yes, by changing the group on those files, you’ve taken permissions away from other users on that server, but what you’re not seeing is that, at the same time, you’re basically giving group permissions to everybody else in the world, via the webserver.”

I think you’re still confused. What does “giving group permissions to everybody else in the world” actually mean? From my two examples above, both scenarios allow “read” access to a script. Setting 640 for a script with “mysite.com:httpd” and setting 644 for a script with “mysite.com:users” is EXACTLY THE SAME for the webserver.

Or did you mean to say something else?

Good plan, indeed.

Clearly, sarcasm is lost on you.

In terms of WP, the only file that you don’t want anyone else to read is “wp-settings.php”.

Your configuration idea doesn’t prevent other users on that server from reading any file at all, wp-settings.php included. That’s what I’m trying to get across to you here.

By allowing “wp-settings.php” to be readable by others, you allow full access to all your precious data in the database.

You do not have the ability to prevent other users with access to your server from reading wp-settings.php, regardless of how you set file permissions. You can prevent them from seeing it by using some clever sudo tricks with the webserver, but it’s not the most obvious way to set up apache and php and such.

Anyway, this is why multi-user servers (for web hosting) have mostly gone away in favor of virtual servers, where each user has his own virtual machine. Heck, we’ve got one downstairs. A single box pretending to be about 150 boxes. Running 150 different operating systems. Simultaneously. It’s pretty fast, too.

I think you’re still confused.

No, I understand *exactly* what I’m talking about. It’s you who is not seeing the full consequences of your described setup.

What does “giving group permissions to everybody else in the world” actually mean? From my two examples above, both scenarios allow “read” access to a script. Setting 640 for a script with “mysite.com:httpd” and setting 644 for a script with “mysite.com:users” is EXACTLY THE SAME for the webserver.

Yes, your settings are exactly the same. Until one of your users sites gets hacked. And then it’s not quite the same any more. That’s the bit you’re failing to see. Your idea for a setup compromizes all users on the server when one of their websites gets hacked.

Or did you mean to say something else?

No, I said exactly what I meant to say. You just didn’t understand it.

It was never my intention for this thread to be hijacked into any “petty” comparirions, but alas, that’s what seems to have happened …

“Your idea for a setup compromizes all users on the server when one of their websites gets hacked.”

How so exactly? You still didn’t explain. I see absolutely NO DIFFERENCE between the two, from the point of view of running a cracked (I prefer the traditional definition of hacking) script over the HTTP protocol. Granted, my proposal is NO MORE secure in this situation. But it’s also NO LESS secure. The difference between them is purely this:

With your method, as an owner of a virtual account on a shared host I can read the database name, user and password for ANOTHER owner of a virtual account on that same host. I then use that information in my own “wp-config.php” and I can do ANYTHING I like to that other owners data.

Anything.

And I can tell you that I CAN DO THIS on at least three hosts I know of.

BTW: I must apologise for an error I made earlier. I was referring to the file “wp-settings.php” which is wrong. What I should have said is “wp-config.php” instead. I can see how this might have caused confusion because it’s the latter which actually stores the database settings.

How so exactly? You still didn’t explain.

I’ve already explained it twice in this thread. I’m done explaining.

With your method, as an owner of a virtual account on a shared host I can read the database name, user and password for ANOTHER owner of a virtual account on that same host. I then use that information in my own “wp-config.php” and I can do ANYTHING I like to that other owners data.

Your method does not prevent me from doing the exact same thing. I explained how above. You’re either not understanding or not reading what I’m saying, and either way, I’m no longer wasting my time with it.

We’re done here.

“Your method does not prevent me from doing the exact same thing.”

Using HTTPD: True. Using SSH: False.

End of discussion.