Re: [RFC] or ACLs

On 09/25/2012 03:19 AM, Amos Jeffries wrote:
> 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.

OK, so no change here.

> Plus a series of http_access allow/deny lines in a row is also an OR set.

OK, so no change here.

> Plus now an "or" type ACL.

What do you mean by "plus"? This is already covered by your first "OR
set of values to be tested" point, is not it?

> 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

I do not understand how either of the above two examples are relevant to
this discussion. You will continue to "correct/optimize slow
configurations" and we will "still have complaints that Squid wont work"
whether we add OR ACLs or not. What we will not have is 120-rule config
where 20 rules would suffice.

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

The number of ways does not increase. We just added one more ACL type,
which has the same overall semantics as most other existing ACL types:
one of the ACL parameters has to match for the whole named ACL to match.
There is nothing really new here.

As for offering a "simplicity vs power vs performance" choice, I think
we should be excited about being able to offer such choice!

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

Nothing is wrong AFAICT. As you mentioned, this config can be optimized
a little at the expense of configuration clarity and simplicity, but
that is admin's choice. It is good to give admins a real choice. Most
admins do not (or should not) care about 2% extra efficiency and prefer
(or should prefer) clear, easily readable, updatable, and documentable
configuration files. This who need those extra 2%, ought to learn how to
optimize (or hire folks like you to help them).

This applies to hand-written and generated configuration files BTW.

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

Why do we suddenly require in-depth wiki tutorials for new ACL types?
Sure, there are often many ways to express configuration rules. And my
proposal will increase the number of ways some configurations can be
written, but why is that a bad thing, and do we really want to make such
explanations a precondition for feature acceptance?

> 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 agree that authentication ACLs are better generated from some user
database, but OR ACLs do not apply just to user authentication. I can
construct the above example using src dstdomain or other ACLs.

And, the script generating configurations can benefit from having access
to OR ACLs, just like a human config writer.

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

Yes, it was. AND is just a natural next step, of course. If I can get OR
without AND, I would rather have that than nothing. However, most of my
arguments and examples apply or can be massaged to apply to AND ACLs as
well.

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

Glad we are in agreement on that.

> I understand; you want to move the entirety of the *_access line
> semantics into "acl" directive.

No, I do not! I just want to allow admins to write natural, efficient,
reusable configurations using basic logic building blocks. I do not want
an admin to create a 120+ rule set where 20 rules will do. There is
currently an artificial barrier in Squid ACL expressions. I want to
remove it.

> Such that one "acl" name can represent
> an entire permission policy and testing procedure.

Yes, but that is not really a primary motivation behind this proposal.
Natural, compact expression of configuration ideas and their reuse are.

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

I agree that if OR is added, there is little reason to resist adding
AND. However, I think this should not be used as an argument against
adding OR (and OR is valuable on its own).

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

I do not think OR or AND ACLs will affect any of that because we already
have to deal with ORed and ANDed ACLs, whether we allow explicit named
groupings or not.

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

Agreed. I just did not want to suggest that we change the overall ACL
syntax as well as add a new ACL type. I wanted to keep the proposal
focused on the essentials.

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

Using a different ACL typename is fine with me. Alternatively, we can do
this if you prefer:

    acl myAcl is acl1 or acl2 or acl3 or acl4

or

    acl myAcl = acl1 or acl2 or acl3 or acl4

This will make the expression very explicit.

No parenthesis and no "and/or" mix would be allowed on a single ACL line
(for now) but this will ease transition to more flexible expressions later.

So, if we change the name to "any/one-of/first-of/etc" or use the "is/="
syntax above, will you be OK with adding OR ACLs?

Thank you,

Alex.
Received on Tue Sep 25 2012 - 15:42:42 MDT