So, having complained about it several times on this list, I finally
sat down to have a serious look at what happens with lookup deferrals
during ACL processing and see if I could fix it.
The fix, as I see it, seems to be the following one-line patch:
--- acl.c.orig Sat Apr 24 03:53:46 2004
+++ acl.c Sat Apr 24 03:54:29 2004
@@ -1046,7 +1046,7 @@
if (expand_string_forcedfail) continue;
*log_msgptr = string_sprintf("failed to expand ACL string \"%s\": %s",
cb->arg, expand_string_message);
- return ERROR;
+ return search_find_defer ? DEFER : ERROR;
}
}
else arg = cb->arg;
Rationale: "DEFER" and "ERROR" are treated almost identically in ACLs
in any case. The difference, though, is that "warn" verbs ignore the
defer. The specification even refers to "some sort of defer" in the
description of the "warn" verb, but in fact all forms of expansion
failures (other than forced failures) were being treated as ERROR, not
DEFER, causing the whole ACL to abort on any sort of lookup failure.
With the above patch, the entire "warn" verb fails (logging a message,
but without taking any other actions) as soon as any of its conditions
causes a deferral, but then proceeds to the next verb in the ACL. This
means that, for example:
warn set acl_c0 = ${lookup ...}
set acl_c1 = 1
will only set acl_c1 to 1 if the lookup did not defer; this allows an
ACL to be written to give any desired behaviour in the event of
deferrals. Configurations not using "warn" should be unaffected by
this change.
--
Andrew, Supernews
http://www.supernews.com
