[squid-users] external acl helpers working with deny_info

[Amos Jeffries]

On 25/01/2016 5:18 a.m., Sreenath BH wrote:
> Hi All,
> 
> I am trying to validate my understanding of external acl, deny_info
> and http_access deny all" interaction.
> 
> My squid conf has just two rules. First is external ACL helper and
> then the "deny all" as follows:
> 
> Case (1)
> -----------
> external_acl_type my_helper ttl=0 negative_ttl=0 children-max=2 %PATH
> /usr/local/bin/acl
> acl AclName external my_helper
> deny_info 404:ERR_MY_ACL      AclName
> http_access allow AclName
> 
> http_access deny all
> --------
> 
> I want a default error code of 404 to be returned, along with a custom
> error message file being sent.
> My observations are as follows:
> 
> 1. If my external ACL prints OK, it proceeds with processing.
> 2. If it prints ERR, instead of using the custom message, it proceeds
> to next access rule, which is "http_access deny all"
> 
> When that fails it prints a default 403 message.
> 
> If I remove "deny all" line it works well.

That is a bug. It should act the same as if the deny all was still there.


> 
> Case (2)
> I tried changing "http_access  allow" to "http_access deny" follows:
> 
> --------
> external_acl_type my_helper ttl=0 negative_ttl=0 children-max=2 %PATH
> /usr/local/bin/acl
> acl AclName external my_helper
> deny_info 404:ERR_MY_ACL    AclName
> http_access deny !AclName
> 
> http_access deny all
> ----------
> 
> In this case, whenever the acl helpers send "ERR", it prints the
> correct error message.
> But now, if it succeeds (prints OK), it goes to next line and fails
> there, instead of proceeding with further processing.
> 
> Even in this case, removing the next "deny all"  will work correctly.
> 
> I find is strange that even when external ACL Helper matches and
> prints OK, because of the way
> the http_access line worded, it does not take it as a pass and goes to
> check next http_access line.

You seem to be confusing the OK/ERR helepr protocol codes with HTTP
pass/reject actions.

* OK is not a "pass" it is a "match"

* the "!" means inversion of the match/mismatch value

So the !AclName means ERR is now a match and OK is a non-match.


When the !AclName is a match the request is denied as per your rule and
using the deny_info details in the rejection message.

When the !AclName is a mis-match it skips and the "deny all" line denies
the request.

When you remove the "deny all" line the default action for this case #2
becomes "allow all".

> 
> Is this expected behavior? Or am I missing something?


deny_info is the directive tying some specific output to an ACL name.
Which is to be sent if (and only if) that ACL was used on a "deny" line.

The bug in case #1 is that the last tested ACL is considered to be the
reason for denial and its action performed when a deny happens. But
without that explicit "deny all" the last tested was actually your ACL
test on the "allow" line.

case #2 is expected behaviour.


Amos