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.
Received on Tue Sep 25 2012 - 00:45:38 MDT