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
