[squid-users] external acl helpers working with deny_info

[Sreenath BH]

Hi Amos,

Thanks for detailed explanation.

For the case #1 in my original post, is it a bug that will get fixed some time?

I was able to get the behavior I want by adding a dummy ACL as follows
(after the external ACL line):

acl myacl src all
deny_info ERR_XXXXX myacl
http_access deny myacl

http_access deny all

myall is same as all, but now even after retaining "http_access deny
all", it works correctly.
With the above, even the "message" that was set in the  external acl
helper was also properly used in the error page.

I am just not sure it is the right way to do it.

Thanks,
Sreenath


On 1/25/16, Amos Jeffries <squid3 at treenet.co.nz> wrote:
> 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
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>