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

On 09.05.2012 07:36, Alex Rousskov wrote:
> On 05/08/2012 01:17 PM, Henrik Nordström wrote:
>> tis 2012-05-08 klockan 12:41 -0600 skrev Alex Rousskov:
>>> This thread started with a suggestion to add "reason"
>>> information to
>>> the allow_t enum type so that ACL check answers can be split into
>>> primary yes/no/other return code and supplementary code-specific
>>> information.

+1 on the patch proposed.

FWIW: a patch like that was the initially planned stage-2 after
converting all ACL handlers from bool/int to to allow_t enum.

>>
>> There is a number similar directives
>>
>> tcp_outgoing_*
>> clientside_*
>> adaptation_meta
>>
>> maybe more.
>>
>> Do your approach fit for these as well?
>
> Yes. Moreover, our new approach supports slow ACLs while the above
> options cannot do that without adding complex-looking and inefficient
> code that essentially duplicates internal ACL looping functionality.
>
> AFAICT, the first two (tcp_outgoing_* and clientside_*) can be
> supported
> with the same allow_t structure because they can encode the matching
> "mark" using an integer data member. Supporting adaptation_meta would
> require a more complex data member to store header name and value.
>
> The approach should be extended to make that extra member depend on
> the
> ACL list type or perhaps point back to the matched ACL list (so that
> the
> caller can figure out what exactly was matched), but this is all
> beyond
> the scope of both this thread or bump-server-first work.
>
> There are caveats to using custom ACL keywords (mostly revolving
> around
> the implicit "negate the last keyword" rule), but this is the wrong
> thread to discuss them.

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.

Amos
Received on Tue May 08 2012 - 22:47:17 MDT