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

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.
>
> 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.

Cheers,

Alex.
Received on Tue May 08 2012 - 19:36:36 MDT