What does the apache Satisfy directive do?
I stumbled upon a httpd.conf
directive that I can't manage to understand:
<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>
According to the doc , I would say that Satisfy
doesn't have any effect since there is no Allow
. Am I wrong? What do you think this directive does?
TLDR;
In most cases this line is not strictly necessary, as Satisfy All
is usually the default server setting. If that's the case, the line is not strictly necessary.
The line is added as extra security, "Just In Case" the server was configured to use Satisfy Any
setting as its default.
If the server was purposely set using the Satisfy Any
setting, you definitely want to override that setting by including the Satisfy All
directive to secure files such as .htaccess
.
I am not sure if the htaccess file would override the server's default 'Satisfy` directive for all folders at or below some said htaccess file.
For generic code posted on the internet, especially when it's telling you how to properly secure .htaccess
files, the poster is being responsible by not making any assumptions about your server settings that could undermine the document's security. Including that "extra" line ensures that the more secure setting is applied to your htacess files. Adding the directive makes the code block work 100% of the time, instead of leaving to chance having htaccess files exposed, for the small set of servers that are configured differently.
As per the apache documentation:
Satisfy Any|All
:Both host-based access restrictions and password-based authentication may be implemented simultaneously. In that case, the Satisfy directive is used to determine how the two sets of restrictions interact.
...used in
<Directory>
,<Files>
, and<Location>
sections as well as.htaccess
This directive is only useful if access to a particular area is being restricted by both username/password and client host address. In this case the default behavior (All) is to require that the client passes the address access restriction and enters a valid username and password. With the Any option the client will be granted access if they either pass the host restriction or enter a valid username and password.
Since the default value usually is Satisfy All
(the only other option is Satisfy Any
), you might not notice a difference when you include that directive. However, your server configuration file (or ?maybe an .htaccess file in a parent directory?? - I'm not sure if this is possible or not) might override the server default. Either way, adding the Satisfy All
directive consistently ensures the proper security measure is applied.
By including the Satisfy All
directive, you ensure the higher security setting for those files, independent of the setting in your server config.
The linked to doc mentions some use cases of when you might want to instead use Satisfy Any
.
Since I cannot comment, I'll add here that @SherylHohman's answer is the best answer because it is important for added security. So, it's not technically true to say that it has no effect without it (in contrast to the accepted answer) since you still have to account for the rest of the server configuration. I would, however, like to add to @SherylHohman's answer:
The server configuration file (e.g.
/etc/httpd/conf/httpd.conf
) could have a more generalizedSatisfy Any
statement. For example, this is important since it's possible someone may require a username/password to access all sites on their server (such as viaRequire group [name
) and then allow a bypass from a specific IP or set of IP's viaAllow from [ip]
, so if this were left out,.htaccess
would be opened up because aSatisfy Any
would have had to be declared.The directories at or above a particular
.htaccess
file will not have an impact unless they a<Files>
section that also specifically matches.htaccess
that would then override this rule, along with the server config also containing the necessaryAllowOverride
directives (e.g.Limit
orAll
). I say that it needs to be<File>
because that is what's used in the server configuration and those are processed after<Directory>
level (i.e. root-level.htaccess
). This is because<File>
sections are merged later and it appears to me that.htaccess
is of course processed after the server config.