Re: [RFC] or ACLs

On 25/09/2012 4:49 p.m., Alex Rousskov wrote:
> 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?

We already have "acl" documented as an OR set of value to be tested.
   Plus a series of http_access allow/deny lines in a row is also an OR set.
   Plus now an "or" type ACL.

Today I'm almost constantly correcting/optimizing slow configurations
like this:

  acl me src 127.0.0.1
  acl you src 127.0.0.2
  acl bob src 127.0.0.3

  http_access allow me
  http_access allow you
  http_access allow bob

We also still have complaints that Squid wont work when they configured
(only):

  acl me src 127.0.0.1
  acl you src 127.0.0.2
  acl bob src 127.0.0.3

>
> 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.

That is part of the problem. This makes three ways to configure OR
operation, depending on exactly what one wants to do. Config simplicity,
power or performance.

> 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?

As with all outwardly simple things, the problem is in context and
verbiage ...

  acl me src 127.0.0.1
  acl you src 127.0.0.2
  acl bob src 127.0.0.3

acl users or me you bob

... with "you", "me", "bob" definitions never mentioned again. Whats
wrong? how do you explain that and why it matters.

... and all the wiki documentation which is going to have to go in will
be about how this differs from sequential access lines, and when you
should choose one over the other. Example cases for when it should and
should not be used. etc, etc.

> 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.

Bad example there. Unfortunately it is one which occurs all to often.
User group membership is the wrong thing to hard-code into any software
configuration file. For exactly the reason you point at about botched
membership updates. Remember that all these users are also recorded in
an external authentication database along with a independent group
hierarchy and set management. Most of the tools for that work far better
than Squid manual configuration ever will.

I get the point though.

>
>
> 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?

Now you are adding "AND" acls into the mix. The RFC was about OR alone I
thought. OR makes sence as acl type since all ACLs are OR sets of
values, that one just happens to be value of other ACL results.

Documenting AND as a value set is an altogether new thing. Which for
starters will not be familiar at a glance to us, let alone the admin
with only passing knowledge of ACLs. AND properties inside a test could
be a dangerous surprise.

I understand; you want to move the entirety of the *_access line
semantics into "acl" directive. Such that one "acl" name can represent
an entire permission policy and testing procedure.

And yes it does make a lot of sense to combine it all and drop the
*_access semantics short of allow/deny into the acl directive tree.
However, this only makes sense being explicit user-visible types IFF
both AND and OR are to be used.

NOTE: I'm mindful though of the proposals and projects already workign
towards making allow/deny/authenticate/other results be retruend by ACL
tests, not just the match/non-match/async-pending tristate.

If we must make these types exposed to users I would at least like to
avoid "or" and "and" names. In your above examples they look very out of
place. If we used them inline where one would expect booleans to be
sure, but not as prefix on a whole line of values. I'm sure we can come
up with better names. "one-of"/ "any-of" / "match-one" and "all-of" /
"match-all" seem to make more visual sense when plugged into your above
examples.

> 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.

The recent bugs found in 3.2's ACL processing of multiple external ACLs
on one access line has brought to light a worse CPU hog. Namely:
repeating an entire line of ACL tests after each async lookup on that
line. We need to make Squid remember the ACL which triggered the async
lookup and resume at that point in the access tree instead of the line head.

Amos
Received on Tue Sep 25 2012 - 09:19:43 MDT