WordPress.org

Ready to get started?Download WordPress

Forums

PREVENT wordpress from creating .htaccess file (30 posts)

  1. mcic1984
    Member
    Posted 8 years ago #

    I have set up permalink structures for my WordPress website. For security reasons, my site administrator has integrated the mod_rewrite setting that usually goes in .htaccess into the server configuration files itself. Thus, the mod_rewrite rules in .htaccess isn't necessary - and in fact, causes Internal Server Error (500).

    Is there a way to stop WordPress creating a .htaccess file every time I try editing something? It basically means I get an Internal Server Error (500).

    I have tried:
    a) Creating a blank .htaccess (still throws out a Internal Server Error

    b) CHMOD the .htaccess file (didn't work)

    I want the permalinks to stay, but I don't want WordPress creating a .htaccess file for me.

  2. Chris_K
    Member
    Posted 8 years ago #

    Remove write access for the process running apache on your blog directory oughta do it.

    A blank and read-only .htaccess didn't work?

  3. mcic1984
    Member
    Posted 8 years ago #

    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?

  4. Chris_K
    Member
    Posted 8 years ago #

    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.

  5. vkaryl
    Member
    Posted 8 years ago #

    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.

  6. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    Set the .htaccess up such that the site works properly, then chmod the file to 444.

  7. vkaryl
    Member
    Posted 8 years ago #

    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.

  8. pizdin_dim
    Member
    Posted 8 years ago #

    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.

  9. vkaryl
    Member
    Posted 8 years ago #

    To me, pizdin_dim? If so, I'll check to see if that's possible, thanks.

  10. Samuel B
    moderator
    Posted 8 years ago #

    If you're hosted very few hosts allow going down to 640. You'll get "permission denied" errors.

  11. vkaryl
    Member
    Posted 8 years ago #

    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.

  12. pizdin_dim
    Member
    Posted 8 years ago #

    "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.

  13. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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?

  14. mcic1984
    Member
    Posted 8 years ago #

    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!

  15. pizdin_dim
    Member
    Posted 8 years ago #

    "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?

  16. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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.

  17. Mark Jaquith
    WordPress Lead Dev
    Posted 8 years ago #

    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.

  18. pizdin_dim
    Member
    Posted 8 years ago #

    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?

  19. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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.

  20. pizdin_dim
    Member
    Posted 8 years ago #

    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.

  21. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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*.

  22. pizdin_dim
    Member
    Posted 8 years ago #

    "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.

  23. vkaryl
    Member
    Posted 8 years ago #

    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.

  24. pizdin_dim
    Member
    Posted 8 years ago #

    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.

  25. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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.

  26. pizdin_dim
    Member
    Posted 8 years ago #

    "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?

  27. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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.

  28. pizdin_dim
    Member
    Posted 8 years ago #

    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.

  29. Samuel Wood (Otto)
    Tech Ninja
    Posted 8 years ago #

    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.

  30. pizdin_dim
    Member
    Posted 8 years ago #

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

    Using HTTPD: True. Using SSH: False.

    End of discussion.

Topic Closed

This topic has been closed to new replies.

About this Topic