Mailing List Archive: exim: dev

calling an ACL from an expansion

Index | Next | Previous | View Threaded

jgh at wizmail

Jun 11, 2012, 2:32 PM

Post #1 of 11 (505 views)
Permalink

calling an ACL from an expansion

In a fit of coding insanity I ran up the following:

+ 9. New expansion item ${acl {name}{argument}} to call an ACL. The argument can
+ be accessed by the ACL in $address_data. The expansion result is set by
+ a "message =" modifier and an "accept" return from the ACL.

Is there any value in this going forward?
--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

pdp at exim

Jun 11, 2012, 6:34 PM

Post #2 of 11 (486 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-11 at 22:32 +0100, Jeremy Harris wrote:
> In a fit of coding insanity I ran up the following:
>
> + 9. New expansion item ${acl {name}{argument}} to call an ACL. The argument can
> + be accessed by the ACL in $address_data. The expansion result is set by
> + a "message =" modifier and an "accept" return from the ACL.
>
> Is there any value in this going forward?

Is there a reason to reuse $address_data? It seems unwise.

Folks passing data down using $address_data, letting content be
${extract}ed from it, may well want to log/process data from that, but
also have something else be passed in as the ACL argument. Eg,
${extract{usercode}{$address_data}} for log-purposes, showing that
delivery was done by authenticating as that usercode.

If there's no specific reason to override $address_data, just add a new
variable.

If the ACL returns non-accept, does that cause an immediate expansion
failure? Does it count as a forced failure?

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

snabb at epipe

Jun 12, 2012, 1:50 AM

Post #3 of 11 (484 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-12 04:32, Jeremy Harris wrote:
> In a fit of coding insanity I ran up the following:
>
> + 9. New expansion item ${acl {name}{argument}} to call an ACL. The
> argument can
> + be accessed by the ACL in $address_data. The expansion result is
> set by
> + a "message =" modifier and an "accept" return from the ACL.
>
> Is there any value in this going forward?

I like this idea. We already have "acl = some_other_acl" syntax which
allows calling other ACLs as if they were subroutines/functions. Passing
arguments to and return values from these subroutines currently requires
using individually named global $acl_* variables, which is ugly.

The proposed interface would allow making generic ACL subroutines
without needing to pass around their arguments in global variables.

Phil's comment is valid: there is no point in overloading an existing
variable to be used for the subroutine argument(s).

This makes me think: perhaps the facility could also allow multiple
arguments, as in ${acl {name}{argument1}{argument2}{argument3}}.

The subroutine/sub-acl could receive these arguments in $arg1, $arg2,...
variables and also supply $argn which gives the number of supplied
arguments?

--
Janne Snabb / EPIPE Communications
snabb [at] epipe - http://epipe.com/

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 12, 2012, 11:54 AM

Post #4 of 11 (486 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-12 02:34, Phil Pennock wrote:
> On 2012-06-11 at 22:32 +0100, Jeremy Harris wrote:
>> In a fit of coding insanity I ran up the following:
>>
>> + 9. New expansion item ${acl {name}{argument}} to call an ACL. The argument can
>> + be accessed by the ACL in $address_data. The expansion result is set by
>> + a "message =" modifier and an "accept" return from the ACL.
>>
>> Is there any value in this going forward?
>
> Is there a reason to reuse $address_data? It seems unwise.
>
> Folks passing data down using $address_data, letting content be
> ${extract}ed from it, may well want to log/process data from that, but
> also have something else be passed in as the ACL argument. Eg,
> ${extract{usercode}{$address_data}} for log-purposes, showing that
> delivery was done by authenticating as that usercode.
>
> If there's no specific reason to override $address_data, just add a new
> variable.

OK, that doesn't seem too hard.

>
> If the ACL returns non-accept, does that cause an immediate expansion
> failure? Does it count as a forced failure?

I've made it cause a failure, but I'm not sure of what type....
It's in expand_string_internal() like the notdef
case of EITEM_DLFUNC.

--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 12, 2012, 11:58 AM

Post #5 of 11 (485 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-12 09:50, Janne Snabb wrote:
> On 2012-06-12 04:32, Jeremy Harris wrote:
>> In a fit of coding insanity I ran up the following:
[...]
>> Is there any value in this going forward?
>
[...]
> This makes me think: perhaps the facility could also allow multiple
> arguments, as in ${acl {name}{argument1}{argument2}{argument3}}.
>
> The subroutine/sub-acl could receive these arguments in $arg1, $arg2,...
> variables and also supply $argn which gives the number of supplied
> arguments?

It could be done. Question: would you also want the existing modifier
extended to support

acl = acl_name arg1 arg2 ...

?

--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

pdp at exim

Jun 12, 2012, 7:43 PM

Post #6 of 11 (484 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-12 at 19:54 +0100, Jeremy Harris wrote:
> > If the ACL returns non-accept, does that cause an immediate expansion
> > failure? Does it count as a forced failure?
>
> I've made it cause a failure, but I'm not sure of what type....
> It's in expand_string_internal() like the notdef
> case of EITEM_DLFUNC.

That's non-forced.

Non-forced errors are supposed to be syntax errors which are
panic-worthy, etc.

Part of the problem here is that ACLs typically return something close
to boolean + error cases, but you've got string expansion. I take it
that a defer return which sets message will expand successfully to that
message?

Should this instead be an expansion condition with a side-effect of
setting $value in both the true and false branches?

ACLs can return: OK DEFER FAIL ERROR.

The OK case is easy, we'll ignore that and just consider the other
three.

By my reckoning, ERROR is the only one of the three which should not
count as a forced failure, if they map to expansion failure. Whether
they do or not presumably depends upon whether or not message was set?

IF either DEFER or FAIL can result in expansion failure, then for those
two ACL return codes, the expansion operator should set
expand_string_forcedfail so that it becomes "fails by policy", rather
than "fails by misconfiguration".

(Why yes, we are using one word for two different meanings and just
tacking on "forced" to distinguish between them)

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 13, 2012, 1:42 PM

Post #7 of 11 (478 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-13 03:43, Phil Pennock wrote:
> On 2012-06-12 at 19:54 +0100, Jeremy Harris wrote:
>>> If the ACL returns non-accept, does that cause an immediate expansion
>>> failure? Does it count as a forced failure?
>>
>> I've made it cause a failure, but I'm not sure of what type....
>> It's in expand_string_internal() like the notdef
>> case of EITEM_DLFUNC.
>
> That's non-forced.
[...]
> I take it
> that a defer return which sets message will expand successfully to that
> message?

Currently, no. I have
accept - OK - expansion from message
defer - DEFER - empty expansion
deny - FAIL - non-forced fail
oops - ERROR - non-forced fail

It seems reasonable to change FAIL to be a forced failure,
but then we can't use accept vs. deny as the obvious true vs. false
if we want to have a direct boolean result (as an expansion condition).

Modifying ERROR to be anything but a (non-forced) fail doesn't seem
right.

>
> Should this instead be an expansion condition with a side-effect of
> setting $value in both the true and false branches?

I did wonder about that. It would make use in a foreach/forany/filter
possibly neater. Though - OK give true seems fine, but what to give
false?

I'll have to look what it would do to reduce
(the doc doesn't say what happens on a forced-fail for string3).

>
>
> ACLs can return: OK DEFER FAIL ERROR.
>
> The OK case is easy, we'll ignore that and just consider the other
> three.
>
> By my reckoning, ERROR is the only one of the three which should not
> count as a forced failure, if they map to expansion failure. Whether
> they do or not presumably depends upon whether or not message was set?

I'd not considered using message in that way.

>
> IF either DEFER or FAIL can result in expansion failure, then for those
> two ACL return codes, the expansion operator should set
> expand_string_forcedfail so that it becomes "fails by policy", rather
> than "fails by misconfiguration".
>
> (Why yes, we are using one word for two different meanings and just
> tacking on "forced" to distinguish between them)

How about:

accept - OK - true + message
defer - DEFER - forced fail
deny - FAIL - false + message
oops - ERROR - non-forced fail

(though I don't see any way of using the string result *and* the
boolean result from a single call at present, one might happen in the future)

--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

pdp at exim

Jun 13, 2012, 4:55 PM

Post #8 of 11 (480 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-13 at 21:42 +0100, Jeremy Harris wrote:
> accept - OK - true + message
> defer - DEFER - forced fail
> deny - FAIL - false + message
> oops - ERROR - non-forced fail

Makes sense to me.

> (though I don't see any way of using the string result *and* the
> boolean result from a single call at present, one might happen in the future)

This is the advantage of the conditional, it can just set $value, a
variable which is already used generically like this.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 14, 2012, 3:07 PM

Post #9 of 11 (466 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-14 00:55, Phil Pennock wrote:
> On 2012-06-13 at 21:42 +0100, Jeremy Harris wrote:
>> accept - OK - true + message
>> defer - DEFER - forced fail
>> deny - FAIL - false + message
>> oops - ERROR - non-forced fail
>
> Makes sense to me.
>
>> (though I don't see any way of using the string result *and* the
>> boolean result from a single call at present, one might happen in the future)
>
> This is the advantage of the conditional, it can just set $value, a
> variable which is already used generically like this.

Hmm. This gets ugly on a couple of counts.

- If it's only available as a conditional then you
can only use it in a conditional context - which is
a pain when what you really wanted was the expansion.
- OK, perhaps we support both methods?

- Syntax as a conditional doesn't easily handle variable
numbers of arguments:
${if <cond> {yes}{no}} has troubles with the difference
between <cond> == <acl {name}> and <cond> == <acl {name}{arg}>
(is {yes} an arg for the acl or for the if?)

- wrap <cond> in { } ? ugly, but matches condition saslauthd
- don't wrap name or args in { } ? how to parse?
- wrap name + args in { } but space-sep within?
e.g. ${if acl {name arg1 arg2} {yes}{no}}
also nonstandard, but matches acl modifier "acl = name arg1 arg2..."

I was partway though coding the last option when I noticed saslauthd.
--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jun 27, 2012, 12:48 PM

Post #10 of 11 (410 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

>> On 2012-06-13 at 21:42 +0100, Jeremy Harris wrote:
>>> accept - OK - true + message
>>> defer - DEFER - forced fail
>>> deny - FAIL - false + message
>>> oops - ERROR - non-forced fail

I've pushed a branch called "acl" with this work.

- the traditional "acl =" ACL condition now accepts arguments,
space-separated, after the ACL name:

acl = my_acl_name arg1 arg2

- a new expansion item ${acl {name}{arg}... }
is added. The result of the expansion is given by
the "message =" modifier in the called acl,
which must accept or deny (not defer).

- a new expansion condition "acl {{name}{arg}... }"
is added. The value of the condition is true if
the called acl returns accept; false for deny. The
content given by "message =" is placed in $value.

In all cases the name and arguments are separately
expanded. Arguments are placed in variables
$acl_arg1 to $acl_arg9; zero to nine arguments are
supported. The actual number for the call is placed
in variable $acl_argn.

--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

jgh at wizmail

Jul 1, 2012, 8:18 AM

Post #11 of 11 (389 views)
Permalink

Re: calling an ACL from an expansion [In reply to]

On 2012-06-27 20:48, Jeremy Harris wrote:
> - the traditional "acl =" ACL condition now accepts arguments,
> space-separated, after the ACL name:
>
> acl = my_acl_name arg1 arg2
> - a new expansion item ${acl {name}{arg}... }
> is added. The result of the expansion is given by
> the "message =" modifier in the called acl,
> which must accept or deny (not defer).
>
> - a new expansion condition "acl {{name}{arg}... }"
> is added. The value of the condition is true if
> the called acl returns accept; false for deny. The
> content given by "message =" is placed in $value.
>
> In all cases the name and arguments are separately
> expanded. Arguments are placed in variables
> $acl_arg1 to $acl_arg9; zero to nine arguments are
> supported. The actual number for the call is placed
> in variable $acl_argn.

Since I didn't hear any screams, I've now pushed it to mainline.
--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads