The .htaccess file appears to be being ignored if the AllowOverride None directive is in /etc/httpd/conf/httpd.conf file. This has changed in the newest Apache on Mandrive 2007 ( 2.2.3) This is a security disaster.
This is documented behaviour going back to the origins of Apache.
(In reply to comment #0) > The .htaccess file appears to be being ignored if the AllowOverride None > directive is in /etc/httpd/conf/httpd.conf file. This has changed in the This has been the case forever and works as designed and documented. > newest Apache on > Mandrive 2007 ( 2.2.3) > This is a security disaster. Now I am confused. It would be a security disaster if httpd would apply the settings of .htaccess in the case that AllowOverride is set to None. Do you state that this is the case since 2.2.3?
If you say so. In that case it must be true that AllowOverride default has changed. However, in my case a .htaccess file exists in the directory, but AllowOverride was none, and all of the files in that directory were accessible by everyone. That is simply wrong behaviour. It should work the same as if the .htaccess file is unreadable but there-- ie permission denied, not allowed. I do not have my old httpd.conf files so do not know if the default has changed, but it certainly used to be the case that the .htaccess files controlled the access to teh directory, and I certainly never recall altering the AllowOverride parameter. But the way it works now is just wrong. The default should not be universal access even in the presence of an .htaccess file. Security should be conservative, not liberal.
.htaccess is not a security feature, it's convenience. Speaking of security: Running a software -- which can everyone in the world access -- with default parameters without even looking at them is the root of the evil here. There is still no bug in sight.
Let me try once again. A .htaccess file on a directory should mean that the organizer of that directory wants to place some access control on that directory. That is why apache, when it finds a .htaccess file which it cannot read ( eg due to permissions) it disallows all access. It assumes that the user has made a mistake, which happens. (Good software design is in part trying to figure out what mistakes a user could make and anticipates them). In this case, a .htaccess file exists, and if for some reason the .conf file is changed ( as happens when people upgrade, or reinstall) and if it happens that the config file has AllowOverride None ( which is the default apparently) then suddenly the .htaccess files are ignored. This is a security hole and a bug, no matter if this is how it has always been or not. I am a non- maive user, and I have been bitten. Whether or not I should have known that AllowOverride None disables all .htaccess files or not is irrelevant. Anything which destroys security is a bug. Note that there is nothing in the manual either that states that AllowOverride None makes .htaccess files ignored. Note also that the description of the AllowOverride says that None is the most conservative choice. It is not, it is the most insecure choice. The presence of a .htaccess file should always trigger security, with the default being no access. The default should NEVER be to allow all access if a .htaccess file exists.
FWIW, this is evidently a case of the first myth discussed at http://www.regdeveloper.co.uk/2006/08/01/apache_undead/
> That is why apache, when it finds a .htaccess file > which it cannot read ( eg due to permissions) it disallows all > access. This isn't what you reported. > Note that there is nothing in the manual either that states that > AllowOverride None makes .htaccess files ignored. http://httpd.apache.org/docs/2.2/howto/htaccess.html says: >> The use of .htaccess files can be disabled completely >> by setting the AllowOverride directive to none: http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride says: >> When this directive is set to None, then .htaccess files are >> completely ignored. In this case, the server will not even >> attempt to read .htaccess files in the filesystem.
OK, it is clear that this is not going to be addressed. One of the selling points of Apache is taking security seriously, but in this case tradition is clearly more important than security. It is true that I went by the comments in the .conf file re the AllowOverride and did not see the comment in the documentation that None would disable all .htaccess. Note that the "Myths" clearly states "The only people to use .htaccess should be end-users who want control without having to bug the server admin." Which means that some action on the part of the sysadmin ( changing the AllowOverride to None) either deliberately or by accident ( installing a new version of Apache) can destroy the user's security. I would call that a design bug, but apparently this is a feature, not a bug. I had a bunch of solutions for assignments on a web directlory which was not supposed to be seen by students ( and no I do not want to bury the security deep inside a config file which changes each time the system is upgraded-- security belongs with the stuff being protected, not buried somewhere else) and suddenly discovered it was available to all. ( I had my own machine as allowd in the .htaccess file, so was not surprised that I ccould see the pages.) I will continue to think that this is idiotic behaviour for anyone who takes security at all seriously, but no longer expect that anyone else will pay any attention to my ranting about it, so with this rant will quit.
FWIW, this is evidently a case of the first myth discussed at http://www.regdeveloper.co.uk/2006/08/01/apache_undead/ (In reply to comment #8) > OK, it is clear that this is not going to be addressed. One of the selling > points of Apache is taking security seriously, but in this case tradition is > clearly more important than security. As André already said, .htaccess has nothing to do with security. Except by coincidence, where a user chooses to make it so. > It is true that I went by the comments in the .conf file re the AllowOverride > and did not see the comment in the documentation that None would disable all > .htaccess. Note that the "Myths" clearly states "The only people to use > .htaccess should be end-users who want control without having to bug the server > admin." Which means that some action on the part of the sysadmin ( changing the > AllowOverride to None) either deliberately or by accident ( installing a new > version of Apache) can destroy the user's security. Nonsense. Installing a new version of Apache preserves your existing httpd.conf, including AllowOverride settings. To have messed it up, you must have done something more than just upgrade. > I would call that a design > bug, but apparently this is a feature, not a bug. > > I had a bunch of solutions for assignments on a web directlory which was not > supposed to be seen by students ( and no I do not want to bury the security deep > inside a config file which changes each time the system is upgraded-- If the config file changes, then your upgrade procedure is broken. > security > belongs with the stuff being protected, not buried somewhere else) and suddenly > discovered it was available to all. ( I had my own machine as allowd in the > .htaccess file, so was not surprised that I ccould see the pages.) > > I will continue to think that this is idiotic behaviour for anyone who takes > security at all seriously, but no longer expect that anyone else will pay any > attention to my ranting about it, so with this rant will quit. We also take performance seriously, so if there wasn't an option to disable the htaccess overhead, we'd have to invent one. But this particular behaviour hasn't changed since Apache 1.0 in 1995. That's a long time before someone reported it as a bug.
OK, you want response I guess, so I will give one. .htaccess is and has been advocated in many places as the way to institute security. The reason it is claimed as a myth is precisely because it is so widely practiced. Also it makes much more sense to associate security with the directory that is being secured than it is to burry it in a config file that only the sysadmin is able to get at and forget about. Ie, not only is it widely practiced, it is a sensible practice. Except on a very high volume web sites, the overhead is minimal, and for those high volume sites, having alternatives in the .conf file is a great idea. b) I have suggested time and again, but you are not listening, that if AllowOverride None is there, the presence of a .htaccess file should disallow access, not allow it. Security defaults should NOT, by default, switch off security. Yes, .htaccess CAN be used for other things. I suspect that if you look around the world, by far the greatest use of .htaccess is to limit access to directories-- to impliment security. Ignoring that may be convenient to you, but I still place it in the "That's not a bug, that's a feature" category. c) In the .conf file, AllowOverride None is called "conservative" and no mention is made that this disables .htaccess completely. This is just wrong. Apache, as with all computer programs, is used by people who have other jobs to do and do not memorize the manual. They trust what is written in the sample .conf files. d) apache has changed from Apache1 to apache2 with massive changes to the .conf files structures, changes which continue. Furthermore for most Linux distributions the advice is "reinstall, do not upgrade". That means that on each reinstall .conf files must be recreated. And a simple diff between the old and new is impossible because so many changes have been made. It is simply impossible for anyone without a massive excess of time on their hands to go through each and every one of the options once again to see what it does, to see if it destroys previously built security. One assumes that the defaults Apache puts in will not disable security, especially from a group who claims to value security. And to add insult to injury, Apache claims that this destruction of a security barrier is "conservative" practice. e) The claim "You are the first to complain about this" is the resort of incompetent and shady businesses around the world. I suspect that there are still a number of bugs in apache which have been there since day 1. To dismiss a bug report on that basis is simply idiotic. Read my resoning and argue with that. Do not claim "tradition" to defend a bad security practice. In my opinion, this IS a bug, and for you to defend it on the basis that it has always been there so its OK simply makes you look bad.
Obviously this thread has already gone too far, but I can't resist. What you don't seem to realize is that there are important reasons why you *wouldn't* want apache to need to check for the existence of .htaccess. In particular, this is a significant performance drain for high-traffic static-file sites. So you want to make it impossible to tune apache for high performance, because security may be compromised by admin errors. By the same logic, we should remove the plain-HTTP protocol from the server and only allow SSL/TLS. Otherwise a bad admin could disclose sensitive information to hackers. (Oh, and obviously we also need to remove the AccessFileName directive, since changing this would also cause .htaccess files to be ignored.) In addition, your problem was caused by multiple errors on your end. First, your admin made an error when upgrading. Second, you are not following best practices for avoiding disclosure of confidential information. This information should 1) not be in a web-accessible directory; and 2) have unix file-system permissions forbidding access to the webserver process.
Yes, it has gone on too long and I think both our positions are clear. However, I want nothing of the sort. a) I want at the very least a warning in the .conf file that setting AllowOverride None disables all .htaccess control. b) At the next level, the disabling of .htacceess control should not be overloaded onto a configuration option which also does something else. Put in a separate DisableAccessControl directive, which would make it abundantly clear to administrators. c) Yes, my situation did result from a number of errors, eg, Apache not warning that AllowOverride None disables all .htaccess control and that the description of that option claims it to be the default and to be conservative. Good software design anticipates user's stupidities, and at the very least warns uses where problems could occur. I also notice that you continue to not respond to my suggestions or complaints, but operate in a "blame the user" mode. This report is at the very least feedback, that there is a SECURITY issue here that has bitten at least one user ( and by the rules of all business practice, if one user complains, it probably means 1000 users have had theproblem and not bothered to complain). As I said, from the response I do not believe that you will do anything at all about this. I clearly have no control over that. I will continue to use Apache, but will no longer believe claims that Apache takes security seriously. But I guess that is just my opinion and my problem.
For what it's worth, I find the reporter's proposed change completely logical, although I realize that the backward-compatibility hassles may outweigh the benefits. For good reasons, any nonempty AllowOverride setting raises error 500 if an htaccess file contains a disallowed directive; having "AllowOverride None" behave differently seems like a gratuitous special case. It would make more sense to have a separate directive to skip htaccess processing for server admins who want the performance benefits. In fact, AccessFileName with an empty list would logically do just this; we would just need a syntax for it, such as "AccessFileName none".
I was also surprised by this. I would rather a 500 internal server error than allowing global access to a directory I thought was restricted by .htaccess.
So I believe unruh, Mikel, and I are in agreement that the current semantic of "AllowOverride None" is a gratuitous special case that is harmful to security. I'll recap the argument in case it isn't clear. The normal effect of omitting a directive-type from AllowOverride is to forbid the use of those directives in htaccess; if Apache finds one, it raises a 500 Internal Server Error. This is a good thing: if for any reason a directive-type is removed from AllowOverride in the master configuration, sites using it stop working rather than become vulnerable. With "AllowOverride Foo", where Foo is a hypothetical directive-type that contains zero directives, an htaccess file containing any directives at all would give a 500 error. But when we get to "AllowOverride None", the behavior suddenly changes: in effect, all directives are silently ignored. My web host, DreamHost, centrally manages the master Apache configuration but uses essentially "AllowOverride All". In this way, they leverage the careful thought the developers put into which Apache directives are safe enough for shared hosting to have htaccess context. They expose a limited amount of the remaining functionality through the customer control panel. Comment #4 and comment #9 seem to be claiming that htaccess is not supported for security. I certainly hope that's not the case; if it is, an giant warning in the manual would be warranted, and web hosts will be deprived of a convenient way to offer a safe subset of Apache functionality to their customers. I understand that changing the behavior of "AllowOverride None" would break existing configurations, which is bad. But at least it should be deprecated in favor of a new "AccessFileName none" syntax, which is the completely logical way to say that no access files should be recognized. Then I would like a new syntax, perhaps "AllowOverride RejectAll", to process htaccess files but with no directive-types allowed. Shall I reopen?
I'm sticking my neck out and reopening for the proposal in comment #15. Again, I understand the need not to break existing configurations that use "AllowOverride None", but I would like to call attention to the issue however possible so that web site admins don't make this mistake in the future.
(In reply to comment #15) > Comment #4 and comment #9 seem to be claiming that htaccess is not > supported for security. They don't claim that at all. Open a concise enhancement request for a way to express that the presence of the AccessFileName should cause an error instead of trying to advocate it here.