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
