Re: [RFC] Handle ACLs that are neither denied nor allowed

On 09.05.2012 11:34, Henrik Nordström wrote:
> ons 2012-05-09 klockan 10:47 +1200 skrev Amos Jeffries:
>> IMHO; it is time to really start work towards dropping that negation
>> behaviour for 3.3. Moving instead to a safe default policy for each
>> access control list and if the end of the list is reached (or an
>> absent
>> list) that policy be enacted.
>
> While I agree for http_access and similar, the default negate is very
> handy for never_direct/always_direct and similar where you usually
> use
> only allow rules or only deny rules depending on the kind of setup.

In which cases the default policy should always be the inversion of
what lines are configured.

ie
  always_direct forward-proxy policy default: allow
  always_direct reverse-proxy policy default: deny
  never_direct policy default: deny
  never_direct policy default: deny

Long-term the idea for those is to make the peer pointer one of these
allow_t properties. Right?

   direct_access allow/deny(never)/always/prefer

with policy default: allow.

At worst something like:
  cache_peer_access DIRECT allow/deny acl [acl ...]
or
  cache_peer_access NONE allow/deny acl [acl ...]

With peer details object being the allow_t parameter returned by the
access control on allow lines. With the usual HIER_DIRECT peer standing
in for direct access in the usual selection algorithms.

Amos
Received on Tue May 08 2012 - 23:57:56 MDT