configurable fail-over for policy virtual modules?
Hi, should it be possible to do this: policy { check_something { if (Some-Attribute) { noop } else { reject } } } authorize { check_something { noop = return } } 2.x just gives a parser error, while 3.x also explains it failed to find "check_something" in the "modules" section. Thanks in advance for any insight, Z.
On 16 Jul 2014, at 11:42, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
Hi,
should it be possible to do this:
policy { check_something { if (Some-Attribute) { noop } else { reject } } }
authorize { check_something { noop = return } }
2.x just gives a parser error, while 3.x also explains it failed to find "check_something" in the "modules" section.
Thanks in advance for any insight, Z.
What would check_something be? Is it a module call? Or a condition or a subroutine? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 2014-07-16 20:39, Arran Cudbard-Bell wrote:
On 16 Jul 2014, at 11:42, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
Hi,
should it be possible to do this:
policy { check_something { if (Some-Attribute) { noop } else { reject } } }
authorize { check_something { noop = return } }
2.x just gives a parser error, while 3.x also explains it failed to find "check_something" in the "modules" section.
Thanks in advance for any insight, Z.
What would check_something be? Is it a module call? Or a condition or a subroutine?
In this case I wanted to use such a policy in a switch/case statement to call a specific eap module, see below. In general I suppose anything one can do in a policy with unlang. eap_virtual { switch "%{EAP-VHost-ID}" { case abc { eap_abc } case def { eap_def } [...] } } Z.
On 16 Jul 2014, at 13:58, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
On 2014-07-16 20:39, Arran Cudbard-Bell wrote:
On 16 Jul 2014, at 11:42, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
Hi, should it be possible to do this: policy { check_something { if (Some-Attribute) { noop } else { reject } } } authorize { check_something { noop = return } } 2.x just gives a parser error, while 3.x also explains it failed to find "check_something" in the "modules" section. Thanks in advance for any insight, Z. What would check_something be? Is it a module call? Or a condition or a subroutine?
In this case I wanted to use such a policy in a switch/case statement to call a specific eap module, see below. In general I suppose anything one can do in a policy with unlang.
eap_virtual { switch "%{EAP-VHost-ID}" { case abc { eap_abc } case def { eap_def } [...] } }
Z.
Then yes, see policy.d or policy.conf (in v2.0.x) -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 2014-07-16 21:09, Arran Cudbard-Bell wrote:
On 16 Jul 2014, at 13:58, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
On 2014-07-16 20:39, Arran Cudbard-Bell wrote:
On 16 Jul 2014, at 11:42, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
Hi, should it be possible to do this: policy { check_something { if (Some-Attribute) { noop } else { reject } } } authorize { check_something { noop = return } } 2.x just gives a parser error, while 3.x also explains it failed to find "check_something" in the "modules" section. Thanks in advance for any insight, Z. What would check_something be? Is it a module call? Or a condition or a subroutine?
In this case I wanted to use such a policy in a switch/case statement to call a specific eap module, see below. In general I suppose anything one can do in a policy with unlang.
eap_virtual { switch "%{EAP-VHost-ID}" { case abc { eap_abc } case def { eap_def } [...] } }
Z.
Then yes, see policy.d or policy.conf (in v2.0.x)
Perhaps what I wrote previously was misleading: The above is the policy definition, which I then call in authorize: eap_virtual { ok = return } This is what didn't work (parser error). Z.
Perhaps what I wrote previously was misleading: The above is the policy definition, which I then call in authorize:
eap_virtual { ok = return }
This is what didn't work (parser error).
Ok, then no you can't override return codes from policies currently. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hi, I had asked about something similar before, but this is different. On 2014-07-16 21:09, Arran Cudbard-Bell wrote:
[...]
What would check_something be? Is it a module call? Or a condition or a subroutine?
In this case I wanted to use such a policy in a switch/case statement to call a specific eap module, see below. In general I suppose anything one can do in a policy with unlang.
eap_virtual { switch "%{EAP-VHost-ID}" { case abc { eap_abc } case def { eap_def } [...] } }
Z.
Then yes, see policy.d or policy.conf (in v2.0.x)
Forcing return within a policy doesn't seem to work; the return code propagates correctly but processing doesn't stop. policy { eap_virtual { switch "%{EAP-VHost-ID}" { case abc { eap_abc { ok = return } } case def { eap_def { ok = return } } [...] } } } [...] server inner-tunnel { authorize { [...] eap_virtual } } The same thing happens in unlang (in a block following a conditional statement), e.g: if (&User-Name) { eap_abc { ok = return } } I'm not sure if this is by design? Using v3.0.x (not head but close). Thanks, Z.
Zenon Mousmoulas wrote:
Forcing return within a policy doesn't seem to work; the return code propagates correctly but processing doesn't stop.
Yes. Policies are like subroutines. You can return from a policy, but it doesn't affect the function which called the policy.
I'm not sure if this is by design? Using v3.0.x (not head but close).
It's by design. Alan DeKok.
27 Αυγ 2014, 3:43, ο/η Alan DeKok <aland@deployingradius.com> έγραψε:
Zenon Mousmoulas wrote:
Forcing return within a policy doesn't seem to work; the return code propagates correctly but processing doesn't stop.
Yes. Policies are like subroutines. You can return from a policy, but it doesn't affect the function which called the policy.
Unlang blocks as well?
I'm not sure if this is by design? Using v3.0.x (not head but close).
It's by design.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 27 Aug 2014, at 08:10, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
27 Αυγ 2014, 3:43, ο/η Alan DeKok <aland@deployingradius.com> έγραψε:
Zenon Mousmoulas wrote:
Forcing return within a policy doesn't seem to work; the return code propagates correctly but processing doesn't stop.
Yes. Policies are like subroutines. You can return from a policy, but it doesn't affect the function which called the policy.
Unlang blocks as well?
I'm fairly sure it should return out of unlang blocks.
I'm not sure if this is by design? Using v3.0.x (not head but close).
It's by design.
Yes it's actually quite nice if the return stops at the depth of the policy call. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 2014-08-27 10:42, Arran Cudbard-Bell wrote:
On 27 Aug 2014, at 08:10, Zenon Mousmoulas <zmousm@noc.grnet.gr> wrote:
27 Αυγ 2014, 3:43, ο/η Alan DeKok <aland@deployingradius.com> έγραψε:
Zenon Mousmoulas wrote:
Forcing return within a policy doesn't seem to work; the return code propagates correctly but processing doesn't stop.
Yes. Policies are like subroutines. You can return from a policy, but it doesn't affect the function which called the policy.
Unlang blocks as well?
I'm fairly sure it should return out of unlang blocks.
Using 3.0.4rc2 and such a configuration: server inner_shortcircuit { authorize { mschap update request { EAP-VHost-ID := "%{outer.request:EAP-VHost-ID}" } update control { Proxy-To-Realm := LOCAL } if (&User-Name) { eap_abc { ok = return } } files pap } [...] } Return doesn't seem to "short-circuit the rest of authorize": Wed Aug 27 12:54:03 2014 : Debug: (6) # Executing section authorize from file /etc/freeradius/sites-enabled/inner_shortcircuit Wed Aug 27 12:54:03 2014 : Debug: (6) authorize { Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: calling mschap (rlm_mschap) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: returned from mschap (rlm_mschap) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) [mschap] = noop Wed Aug 27 12:54:03 2014 : Debug: (6) update request { Wed Aug 27 12:54:03 2014 : Debug: (6) EXPAND %{outer.request:EAP-VHost-ID} Wed Aug 27 12:54:03 2014 : Debug: (6) --> abc Wed Aug 27 12:54:03 2014 : Debug: (6) EAP-VHost-ID := "abc" Wed Aug 27 12:54:03 2014 : Debug: (6) } # update request = noop Wed Aug 27 12:54:03 2014 : Debug: (6) update control { Wed Aug 27 12:54:03 2014 : Debug: (6) Proxy-To-Realm := 'LOCAL' Wed Aug 27 12:54:03 2014 : Debug: (6) } # update control = noop Wed Aug 27 12:54:03 2014 : Debug: (6) if (&User-Name) Wed Aug 27 12:54:03 2014 : Debug: (6) if (&User-Name) -> TRUE Wed Aug 27 12:54:03 2014 : Debug: (6) if (&User-Name) { Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: calling eap_abc (rlm_eap) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) eap_abc : Peer sent code Response (2) ID 6 length 14 Wed Aug 27 12:54:03 2014 : Debug: (6) eap_abc : EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: returned from eap_abc (rlm_eap) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) [eap_abc] = ok Wed Aug 27 12:54:03 2014 : Debug: (6) } # if (&User-Name) = ok Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: calling files (rlm_files) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) files : users: Matched entry localuser at line 1 Wed Aug 27 12:54:03 2014 : Debug: (6) files : ::: FROM 0 TO 0 MAX 0 Wed Aug 27 12:54:03 2014 : Debug: (6) files : ::: TO in 0 out 0 Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: returned from files (rlm_files) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) [files] = ok Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: calling pap (rlm_pap) for request 6 Wed Aug 27 12:54:03 2014 : WARNING: (6) pap : Auth-Type already set. Not setting to PAP Wed Aug 27 12:54:03 2014 : Debug: (6) modsingle[authorize]: returned from pap (rlm_pap) for request 6 Wed Aug 27 12:54:03 2014 : Debug: (6) [pap] = noop Wed Aug 27 12:54:03 2014 : Debug: (6) } # authorize = ok While it does work if I remove the unlang block wrapping eap_abc: [...] Wed Aug 27 13:10:17 2014 : Debug: (16) eap_abc : Peer sent code Response (2) ID 6 length 14 Wed Aug 27 13:10:17 2014 : Debug: (16) eap_abc : EAP-Identity reply, returning 'ok' so we can short-circuit the rest of authorize Wed Aug 27 13:10:17 2014 : Debug: (16) modsingle[authorize]: returned from eap_abc (rlm_eap) for request 16 Wed Aug 27 13:10:17 2014 : Debug: (16) [eap_abc] = ok Wed Aug 27 13:10:17 2014 : Debug: (16) } # authorize = ok
I'm not sure if this is by design? Using v3.0.x (not head but close).
It's by design.
Yes it's actually quite nice if the return stops at the depth of the policy call.
OK. If I can't return, I think I can't do this "short-circuit" for eap. Unless I am missing something? Thanks, Z.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Zenon Mousmoulas