[squid-users] acls with the same name, last wins

[Ivan Larionov]

I'm a bit confused now. Examples from default config:

acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl localnet src fc00::/7       # RFC 4193 local private network range
acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged)
machines

acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 1025-65535  # unregistered ports

All these ACL work as OR, right?

Why is req_header different?

On Thu, Dec 29, 2016 at 9:44 PM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 2016-12-29 21:01, Ivan Larionov wrote:
>
>> I see behavior change after update from squid 2.7 to 3.5:
>>
>> I have following ACLs which I later use for cache_peer_access:
>>
>> acl header req_header header_a -i true
>> acl header req_header header_b -i true
>>
>> # name1 parent
>> cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1
>> cache_peer_access name1 deny header
>>
>> # name2 parent
>> cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2
>> cache_peer_access name2 allow header
>> cache_peer_access name2 deny all
>>
>> With squid 2.7 it was working as expected (requests with header_a OR
>> header_b were going to the second parent, all other requests to the
>> first one).
>>
>> However with squid 3.5 the same config doesn't work as expected. ONLY
>> requests with header_b are going to the second parent and debug logs
>> show that squid only does verification of header_b.
>>
>> My current workaround is to use 2 different ACL names:
>>
>> acl header_a req_header header_a -i true
>> acl header_b req_header header_b -i true
>>
>> # name1 parent
>> cache_peer 127.0.0.1 parent 18070 0 no-query no-digest name=name1
>> cache_peer_access name1 deny header_a
>> cache_peer_access name1 deny header_b
>>
>> # name2 parent
>> cache_peer 127.0.0.1 parent 18079 0 no-query no-digest name=name2
>> cache_peer_access name2 allow header_a
>> cache_peer_access name2 allow header_b
>> cache_peer_access name2 deny all
>>
>> But I think it could be a bug. Multiple ACLs with the same name should
>> work as OR, right? Do I understand it correctly? And it was working as
>> expected in 2.7.
>>
>> Has anyone saw similar behavior? Should I report a bug?
>>
>
> Good find. You are the first to mention it.
>
> I have had a look back into the code history and don't see this as ever
> being an intended behaviour for Squid-2. Just a side effect of how the
> Squid-2 ACL lists happened to be stored internally.
>
> The intended design for ACLs is that basic/primitive tests check one piece
> of state data and get chained explicitly in the access lines for AND/OR
> conditions. That way it is clear what is being processed and matched (or
> not matched).
>
> So for now I am making Squid produce a config ERROR when this config
> situation is found. The 'anyof' or 'allof' ACL types in 3.4+ can be used to
> assemble a more complex test set checking different ACL primitives.
>
> Amos
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>



-- 
With best regards, Ivan Larionov.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20161230/8df21a16/attachment.html>