Re: [RFC] or ACLs

On 09/24/2012 05:40 PM, Amos Jeffries wrote:
> On 25.09.2012 10:06, Alex Rousskov wrote:
>> I would like to add support for explicit OR ACLs:
>>
>> # ACL name will match if and only if any of its acl* ACLs match.
>> # The first matching acl (left-to-right) stops evaluation.
>> acl name or acl1 acl2 ...

>> Any objections to this new feature?

> Only to agree with Robert that exposing this functionality adds too much
> difficulty to explain.

Your experience and expertise in this area exceed mine, but I have a
hard time imagining a person who can understand current Squid ACLs and
yet requires some kind of very difficult explanations to understand an
OR ACL. What is so special about an OR ACL that makes it difficult to
explain?

IMHO, any additional explanations would be restricted to the new ACL
type, which is true for any new ACL type, and has no global
implications. It does _not_ change how one reads http_access or other
ACL rules.

FWIW, here is how one could explain the new OR acl type in
squid.conf.documented:

        acl aclname or aclName1 aclName2 ...
            # Matches if any of the specified ACLs match
            # (evaluation stops at the first match).
            # Mismatches if all of the specified ACLs mismatch.

What is so complex about this? If it is not complex, then what is
missing? I think all other explanations about ACLs in general would
apply here without the need for more documentation, no?

> IMO it would be better if this 'or' type was hidden and not usable
> directly in the config.
>
> Instead make it a magic ACL node/type created when we discover two (or
> more) ACL types being assigned to the same *name*. The config dumper for
> it can dump out the well-known acl sub-type lines for each sub-type list
> and nothing for the parent aggregator.
>
>
> For example:
> acl alpha dstdomain .example.com
> acl beta src localhost
> acl foo or alpha beta
>
> http_access allow foo
>
> would instead be configured as:
>
> acl foo dstdomain .example.com
> acl foo src localhost
>
> http_access allow foo
>
>
> This way we have zero extra complexity to explain, except to say the ACL
> may now support multiple types and emphasise the existing documentation
> that 'acl' lines are OR sets, any one value may match.

Agreed, and I would have to leave with this implicit approach if that is
the consensus. However, this approach has two significant limitations, IMO:

1) It does not allow folks to name and reuse complex ACLs. If "a or b"
has a special meaning in my config, I can name it, but I cannot reuse it
elsewhere. I have to start from scratch every time I need to OR "a or b"
with something else:

My proposal:

    # define VIP users using previously defined ACLs:
    acl vip or manager auditor
    # define trusted users using previously defined ACLs:
    acl trusted or vip authenticated

Your proposal:

    # define VIP users from scratch:
    acl vip ... Manager1
    acl vip ... Manager2
    acl vip ... Auditor1
    acl vip ... Auditor2

    # define trusted users from scratch:
    acl trusted ... Manager1
    acl trusted ... Manager2
    acl trusted ... Manager3
    acl trusted ... Auditor1
    acl trusted ... Auditor2
    acl trusted ... Authenticated1
    acl trusted ... Authenticated2
    acl trusted ... Authenticated3

Oops! The "trusted" ACL definition has the wrong Manager because we
updated the "vip" ACL definition last week but forgot to update the
"trusted" one.

2) There is no similar trick to define and reuse AND ACLs.

My proposal:

    acl trusted and authenticated fromEurope
    http_access allow trusted
    peer_access euMirror allow trusted

Current workaround:

    http_access allow authenticated fromEurope
    peer_access euMirror allow authenticated fromAfrica

Oops! The peer_access rule uses the wrong combination of ACLs because we
updated the "http_access" rule when cloning the server but forgot to
update the "peer_access" one.

Together, these new ACLs can accomplish almost everything that Robert
specified as a long-term goal of reusable ACLs.

Do additional explanations, whatever they are, really outweigh these
benefits?

Thank you,

Alex.
P.S. AFAICT explicit AND/OR ACLs are also more efficient (from RAM and
sometimes CPU cycles p.o.v.) than repeating the same raw ACL definition
every time we need to reuse it.
Received on Tue Sep 25 2012 - 04:50:01 MDT