Re: [PATCH] [MEDIUM] access control (block) rework - rfc

From: Krzysztof Oledzki <>
Date: Thu, 29 Jan 2009 01:38:13 +0100 (CET)

On Wed, 28 Jan 2009, Willy Tarreau wrote:


>> We may start with implementing a sequential ordering for req (request) and
>> supporting three default targets: deny, tarpit and allow.
> And "redirect" please ;-)

If we do this right there will be no need to add a special "redirect" target as it should be possible to create it with:

Allowing such possibility *in the right way* is one of my current goals, however as each change requires some thinking and discussing I prefer to finish one stage before starting with a next one. I have developed too many custom patches for haproxy, I really need to clean my code and push them upstream, one by one. ;) Keeping them outside the mainline cost me too much.

> In fact, I think you should not touch "block" for now, as it's evaluated
> very early, independant of this new sequence. We would just have to emit
> a big warning when loading a new config using "block" and suggest moving
> those lines to the top of the ACLs and changing it with "req deny".

Or we may simply handle it as "req deny" + emitting standard "deprecated" warning.

>>> Also BTW, there's something else I had planned. Right now you cannot
>>> write rules without an ACL for whatever object. While this is handy
>>> for complex configs, this is very boring for small configs. I'd like
>>> to be able to use the verb as a function in the rules.
>>> For instance, instead of always having to write :
>>> acl admin src
>>> allow if admin
>>> you could write :
>>> allow if src(
>>> The last changes I made to the rules in order to add better checks
>>> and typing have made that a lot easier. It would of course prevent
>>> caching, as "src(" would automatically be compiled into
>>> an implicit ACL, but caching is still not implemented, and people
>>> who would need caching will certainly not use this anyway because
>>> they'd want to factor out common information.
>> Indeed, your "instant acl's" idea seems very useful. However, I'm not sure
>> if it is OK to distinguish it by parenthesis - how whould you like to
>> write it for "hdr(host) -i localhost"?
> hehe I thought about that this morning when going to work :-)
> Indeed, parenthesis are a bad idea. But having a method for
> grouping is still needed, or at least being able to specify a
> modifier (-i), an operator (-gt, -lt) and a value. Maybe we
> should imply enclose them by parenthesis, something like that :
> req allow if (hdr(host) -i www) (src

OK, but if we do this we should, at the same time, deny creating acls with names containing "acl" and/or parenthesis.

>> Maybe it would be better to add two new keywords: "ifacl" or "unlessacl"?
> If I understand what you propose, I don't think it will solve the
> issue as I don't see how I could combine two ACLs with this method.
> However, a minor modification might consist in having an "acl()"
> function :
> req allow if acl(hdr(host) -i www) ...

Ack, this looks wisely.

>>> That said, I'm clearly in favor of "deny" instead of "block" and
>>> adding "allow" ;-)
>> OK. So if you agree on my "req {allow|deny|tarpit} {if|unless} acl"
>> idea I'll try to rework my patch that way.
> Yes I agree with it provided you also include "redirect" and you
> keep in mind that later we'll make it evolve towards "in" and "out",
> with probably "in" being the default when not specified.

I think we need to discuss more on this "redirect" target. However I believe whatever solution we will choose it should be possible to add it by simply extending current syntax.

> BTW, may be you have noticed, I have updated the master git tree
> on the site (and a snapshot was published yesterday). The HTTP
> part is far more easy to modify without being perturbated by
> lower layers, and vice-versa. Those who want tons of new features
> and new L7 protocols (POP, SMTP) will be happy. At least, I hope :-)

Yep. ;) I have a local copy of the git repository so if I only have enough time I trace each change as soon as you push it. ;)

Best regards,

                         Krzysztof Olędzki Received on 2009/01/29 01:38

This archive was generated by hypermail 2.2.0 : 2009/01/29 01:45 CET