Re: [RFC] or ACLs
On 27.09.2012 03:18, Kinkie wrote:
Here's my cue :-)
I tend to favor expressiveness, and I'd love to see the access rules
evolve
to a tree-like structure, with sub expressions and explicit Boolean
operators.
But I also think that the one-of / all-of proposal is clear and is
more
expressive than what we have now, so I support it.
On Wednesday, September 26, 2012, Alex Rousskov wrote:
On 09/25/2012 09:02 PM, Amos Jeffries wrote:
>> 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 ?
"is" means what it means in English: equality or definition.
> Does '=' means OR or AND or assignment ?
"=" means what it means in programming: equality or assignment.
The expression on the right hand side determines what is being
assigned.
Since neither of us liked "or acl1 acl2" style, I proposed "is acl1
or
acl2" style because it is natural and will allow us to support more
complex expressions later. I now understand that you do not like
that
direction, so I will use "one-of" you suggested unless others help
form
a different consensus.
> 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.
I will use your "one-of"/"all-of" names.
> 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.
I am glad AND/OR ACLs will be allowed.
It is unfortunate that our views on what the ideal Squid
configuration
language should provide (and how to get to that ideal) differ so
much. I
focus on maximizing flexibility and expressiveness of the language
while
you focus on minimizing misuse and abuse. I cannot think of any
real-world example where humanity succeeded optimizing in _both_
directions. While both expressiveness and safety are good principles
and
usually co-exist, one principle has to dominate for the design to
flourish.
On the contrary. The "safe" route I would I would very much like to see
is one day to have the very flexible and expressive syntax:
acl label = (condition)
Where condition contains at least 'or', 'and', '(', ')', '!' operators
to construct a true boolean tree structure for the ACL test. That syntax
has much wider understanding than our existing definition structure and
will cause far less confusion overall.
If you want this project to jump straight to that for 3.4 I have no
problem with the naming. It is only for this half-stage where its almost
there but missing vital bracket/scoping operators that I am concerned
about understanding and migration problems.
IMHO its not that much work to add a Conditional data type which hold
ACL node pointers instead of data values to test against. With a
strategy for each operator type. The parser would need to be
semi-recursive like any boolean parser - but that is not a big problem.
HTH
Amos
Re: [RFC] or ACLs
On 9/26/2012 5:07 PM, Alex Rousskov wrote: I am glad AND/OR ACLs will be allowed. It is unfortunate that our views on what the ideal Squid configuration language should provide (and how to get to that ideal) differ so much. I focus on maximizing flexibility and expressiveness of the language while you focus on minimizing misuse and abuse. I cannot think of any real-world example where humanity succeeded optimizing in_both_ directions. While both expressiveness and safety are good principles and usually co-exist, one principle has to dominate for the design to flourish. Now that the solution to an immediate practical problem has been agreed on, I do not think it makes sense to continue this discussion between the two of us. Hopefully, others will chime in and help form a consensus, but I am not optimistic. Thank you, Alex. I was thinking and what AND/OR different from the ACLs as it now? today it's a strict "AND" for the whole line so in a sense of calculator it's: http_access allow AND acl1 acl2 acl4 (+1,2,3,4) which is the better choice if you do ask me for acl validation instead of using: http_access allow AND acl1 AND acl2 AND acl4 (1+2+3+4) (I dont remember the literal way of the different ways to this calculation thing) If you do ask me one of the best things I do like about squid configuration is not having a "programming language" like structure. Ff you will take for example varnish configuration. you will need to learn how it all fits together to even write the basic configurations while with squid you can simply write: one acl for src allow one cache_peer directive + allow\deny acl one http_acces \ https_access and refresh_pattern if needed at all So I think that adding the feature OR like this: http_access allow acl1 acl2 acl4 OR acl5 acl6 http_access allow OR acl7 acl8 when the OR is only on acls after the OR will be accounted as OR can be understandable and will not effect any current configurations. Flexibility is a good thing but IN steps. What I mean is that the current configuration syntax is based on static statements which can be understood in seconds for almost anyone who just read it. The way system administrators looks at the product can be seen from couple angles like: while they need the product. while they need the product to do something specific. while they have a product the was used before. and maybe some other points of view of course. While they prefer the software to have "all they need" to do a specific task they would admit that in other points encountering the product they prefer simplicity. I would ask just to now if i'm wrong or not: all this big list of http_access deny w1 r2 http_access deny w2 r2 http_access deny w3 r2 http_access deny w4 r2 http_access deny w5 r2 can be replaced with one external_acl helper? (since I do not know what w1 and r1 acls are). Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer ngtech.co.il
Re: [RFC] or ACLs
On 09/25/2012 09:02 PM, Amos Jeffries wrote: >> 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 ? "is" means what it means in English: equality or definition. > Does '=' means OR or AND or assignment ? "=" means what it means in programming: equality or assignment. The expression on the right hand side determines what is being assigned. Since neither of us liked "or acl1 acl2" style, I proposed "is acl1 or acl2" style because it is natural and will allow us to support more complex expressions later. I now understand that you do not like that direction, so I will use "one-of" you suggested unless others help form a different consensus. > 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. I will use your "one-of"/"all-of" names. > 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. I am glad AND/OR ACLs will be allowed. It is unfortunate that our views on what the ideal Squid configuration language should provide (and how to get to that ideal) differ so much. I focus on maximizing flexibility and expressiveness of the language while you focus on minimizing misuse and abuse. I cannot think of any real-world example where humanity succeeded optimizing in _both_ directions. While both expressiveness and safety are good principles and usually co-exist, one principle has to dominate for the design to flourish. Now that the solution to an immediate practical problem has been agreed on, I do not think it makes sense to continue this discussion between the two of us. Hopefully, others will chime in and help form a consensus, but I am not optimistic. Thank you, Alex.
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 membe
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
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
Re: [RFC] or ACLs
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? 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. 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? 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. 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? 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.
Re: [RFC] or ACLs
On 09/24/2012 04:32 PM, Robert Collins wrote: > On Tue, Sep 25, 2012 at 10:06 AM, Alex Rousskov wrote: >> >> I would like to add support for explicit OR ACLs: > I'd like to see, long term, some more complete language - e.g. > something with macros so you can define and reuse complex constructs > without having to repeat them, which I think your OR support will only > partially mitigate against. The existing language is already functionally complete. Adding OR and AND ACLs will allow admins to "define and reuse complex constructs without having to repeat them". Is not that exactly what you would like to see, and is not that much better than "macros" as far as ACL definition and reuse are concerned? The only thing that would still be missing is ability to construct expressions on the fly, without naming every AND or OR sequence. For example, writing "(a or (b and !c))" would still be impossible. That can be supported as the next step though (reusing much simpler the code I propose to add now): acl future is a or (b and !c) Thank you, Alex.
Re: [RFC] or ACLs
On 09/24/2012 05:46 PM, Amos Jeffries wrote: > On 25.09.2012 10:06, Alex Rousskov wrote: >> Hello, >> >> 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 ... >> >> >> As you know, existing Squid ACL rules are meant to be functionally >> complete: they can express any combination of logical conditions >> expressed by individual ACLs. However, specifying the right combination >> may require a very long and confusing configuration file. >> >> I recently came across a real-world case where 20 reasonable http_access >> access rules had to be converted into more than 100 rules just to add a >> single "or the user does not need authentication" condition into the >> "middle" of an existing rule set. The solution was so "big" and required >> such a rewrite of the existing rules that the admin thought that it >> would be impossible to support his needs using Squid ACLs! > > > Can you let me have a look at this config before and after? > I'm having difficulty figuring out / understanding how a single boolean > test condition can inflate the stanza by more than 50% when the NAND > operation is available. I think the real case can be distilled to this: # authenticate except for certain whitelisted transactions; # whitelisting must be expressed by ANDing five negated ACLs: http_access deny !w1 !w2 !w3 !w4 !w5 !REQURED_AUTH # 20 primary rules (for authenticated or whitelisted transactions) http_access deny r1 http_access deny r2 ... http_access deny r20 # this is the only "allow" rule http_access allow all And now the manager comes and says "please do not authenticate POST requests from Opera browsers". Needless to say, all 20 primary access control rules must still apply, and must still apply after authentication if authentication is required. The admin wants to say something like this: acl special and browserIsOpera methodIsPost http_access deny !w1 !w2 !w3 !w4 !w5 !special !REQURED_AUTH or, preferably, even this: acl special and browserIsOpera methodIsPost acl whitelisted or w1 w2 w3 w4 w5 special http_access deny !whitelisted !REQURED_AUTH but he cannot because and/or ACLs are not supported. My solution (without Squid modifications) was this: # Duplicate 20 primary rules. For each duplicated rule, # use 6 rules, one for each whitelisting rule (20x6) http_access deny w1 r1 http_access deny w2 r1 http_access deny w3 r1 http_access deny w4 r1 http_access deny w5 r1 http_access deny browserIsOpera methodIsPost r1 http_access deny w1 r2 http_access deny w2 r2 http_access deny w3 r2 http_access deny w4 r2 http_access deny w5 r2 http_access deny browserIsOpera methodIsPost r2 ... http_access deny w1 r20 http_access deny w2 r20 http_access deny w3 r20 http_access deny w4 r20 http_access deny w5 r20 http_access deny browserIsOpera methodIsPost r20 # now allow access to whitelisted folks since they # did not match any of the r1...r20 rules http_access allow w1 ... http_access allow w5 http_access allow browserIsOpera methodIsPost # updated authentication rule here # bonus: no need to check whitelisting anymore! http_access deny !REQURED_AUTH # old 20 final rules here (for authenticated folks) http_access deny r1 http_access deny r2 ... http_access deny r20 http_access allow all I hope I got the above right. If my math is correct, we started with 1+20+1 = 22 http_access rules. We ended up with approximately 20*6 + 6 + 1 + 20 + 1 = 148 rules. Is there a better internal ACL-based solution without adding "and/or" ACLs or equivalent? Cheers, Alex.
Re: [RFC] or ACLs
On 25.09.2012 10:06, Alex Rousskov wrote: Hello, 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 ... As you know, existing Squid ACL rules are meant to be functionally complete: they can express any combination of logical conditions expressed by individual ACLs. However, specifying the right combination may require a very long and confusing configuration file. I recently came across a real-world case where 20 reasonable http_access access rules had to be converted into more than 100 rules just to add a single "or the user does not need authentication" condition into the "middle" of an existing rule set. The solution was so "big" and required such a rewrite of the existing rules that the admin thought that it would be impossible to support his needs using Squid ACLs! Can you let me have a look at this config before and after? I'm having difficulty figuring out / understanding how a single boolean test condition can inflate the stanza by more than 50% when the NAND operation is available. Amos
Re: [RFC] or ACLs
On 25.09.2012 10:06, Alex Rousskov wrote: Hello, 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 ... As you know, existing Squid ACL rules are meant to be functionally complete: they can express any combination of logical conditions expressed by individual ACLs. However, specifying the right combination may require a very long and confusing configuration file. I recently came across a real-world case where 20 reasonable http_access access rules had to be converted into more than 100 rules just to add a single "or the user does not need authentication" condition into the "middle" of an existing rule set. The solution was so "big" and required such a rewrite of the existing rules that the admin thought that it would be impossible to support his needs using Squid ACLs! If OR ACLs are supported, no drastic increase in http_access rules would be required to solve the same problem. Explicit OR (and AND) ACLs also allow an admin to group related ACLs of different types together and name them. This can be used to simplify and self-document configurations. IIRC the subject of explicit OR ACL support has came up recently on one of the squid-dev threads, and there were positive remarks about adding them. Any objections to this new feature? Only to agree with Robert that exposing this functionality adds too much difficulty to explain. 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. Amos
Re: [RFC] or ACLs
On Tue, Sep 25, 2012 at 10:06 AM, Alex Rousskov wrote: > Hello, > > I would like to add support for explicit OR ACLs: On the up side i think that this would indeed give us much more flexability, and its a decent stopgap between this and a more understandable ACL language. On the downside, I think it will make things harder to explain, the current system being itself rather arcane. I'd like to see, long term, some more complete language - e.g. something with macros so you can define and reuse complex constructs without having to repeat them, which I think your OR support will only partially mitigate against. -Rob
[RFC] or ACLs
Hello, 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 ... As you know, existing Squid ACL rules are meant to be functionally complete: they can express any combination of logical conditions expressed by individual ACLs. However, specifying the right combination may require a very long and confusing configuration file. I recently came across a real-world case where 20 reasonable http_access access rules had to be converted into more than 100 rules just to add a single "or the user does not need authentication" condition into the "middle" of an existing rule set. The solution was so "big" and required such a rewrite of the existing rules that the admin thought that it would be impossible to support his needs using Squid ACLs! If OR ACLs are supported, no drastic increase in http_access rules would be required to solve the same problem. Explicit OR (and AND) ACLs also allow an admin to group related ACLs of different types together and name them. This can be used to simplify and self-document configurations. IIRC the subject of explicit OR ACL support has came up recently on one of the squid-dev threads, and there were positive remarks about adding them. Any objections to this new feature? Thank you, Alex. P.S. I do _not_ plan to support grouping/parenthesis and explicit AND/OR operations in ACL lists. For example, the following will _not_ be supported by this project: http_access deny foo and ( bar or baz ) However, if there is consensus that such support is needed, it can be added by others using the proposed AND/OR ACLs. Those ACLs would just have to be created automatically rather than being explicitly named by the admin.
