Re: [RFC] or ACLs

On 26.09.2012 03:42, Alex Rousskov wrote:
> 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.

"
   Sure, there are often many ways to express configuration rules. And
my
   proposal will increase the number of ways some configurations can be
   written,
"

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

Because this has stepped 'acl' directive scope from matching particular
a traffic meta data. To abstracting an entire policy. If it is to be
useful we need to document it for people to find easily and understand
better.

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

We already do. A feature description page in the wiki outlining whet
use-cases it is for and why/when people want to use it.

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

But, but. That is what will happen as a direct downstream result of
these additions.

AND and OR semantics move into a tree of ACL definitions. No more need
for multiple ACL names on one http_access line. No more multiple
allow/deny lines in a row (one 'or' ACL line does that whole listing).
  ==> *_access become just a list of things allowed/denied and the
ordering of which action applies first. Then we make teh leaf node
produce the action itself... and bye-bye *_access.

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

I'm thinking the reverse. These will need re-design later for how we
merge sub-ACL results when two of the list are producing different
specialty actions and the grouping 'and' ACL can only return one object.
Not that its a problem, just something to keep in mind for long-terms
affects this is going to have on the config usability.

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

True. but, I don't prefer it. KISS / Baby steps etc. Getting the
type(s) available and people comfortable with them is enough for now.

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

That is a slight problem and probably good cause for avoiding that
syntax for now.

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

Does 'is' mean OR or AND or IF or equals ?

Does '=' means OR or AND or assignment ?

Please consider names that provide you with easily distinguishable set
of types that still match the underlying semantics. "one-of"/"all-of" at
least hint at the OR/AND set semantics.

To summarise: Yes I'm okay with adding OR type. Provided the larger
picture is considered when adding them.

  You may as well add the AND type as well, since they only differ in
match() strategy. Then you have grounds for adding a Conditional.h/cc to
src/acl which defines these and any future boolean node types.

Amos
Received on Wed Sep 26 2012 - 03:02:57 MDT