Recursive string expansion
I have an issue with recursive string expansion -- that is, it is recursing in a situation where I'd rather it didn't. Specifically, with freeradius 3.0.13, in policy.d/moonshot_targeted_ids, if I set targeted_id_salt = '${changeme' then I get the error: Fri May 26 20:23:37 2017 : Error: /etc/freeradius/policy.d/moonshot-targeted-ids[40]: Reference "${changeme%{tolower}" not found Fri May 26 20:23:37 2017 : Error: Failed expanding section name Fri May 26 20:23:37 2017 : Error: /etc/freeradius/policy.d/moonshot-targeted-ids[41]: Failed allocating memory for section Fri May 26 20:23:37 2017 : Error: Errors reading or parsing /etc/freeradius/radiusd.conf This seems to be a reference to these two lines (starting at line 40) : if (&outer.request:GSS-Acceptor-Host-Name) { if ("%{echo:/usr/bin/uuid -v 5 ${policy.moonshot_host_namespace} %{tolower:%{User-Name}}${policy.targeted_id_salt}%{tolower:%{outer.request:GSS-Acceptor-Host-Name}}}" =~ /^([^ ]+)([ ]*)$/) { So it definitely looks like ${policy.targeted_id_salt} is expanded once, and then something attempts to expand the expanded string, which fails because '${changeme' is invalid xlat syntax. I haven't found any user documentation indicating whether string expansion is recursive. I did find an older post by Arran where he says that "rlm_sql does recursive xlat" (see (http://lists.freeradius.org/pipermail/freeradius-users/2009-April/037249.htm...). This makes me wonder whether this behavior is decided upon by the module's implementer. If there is a way to prevent this behavior (i.e., force a string to be expanded non-recursively), I'd love to hear about it. I'd be happy to file a bug (or feature request) if that would be appropriate. Thanks, Dan Breslau
Try 3.0.14... 'moonshot-targeted-ids' says: If you use special characters %, { and }, escape them with a \ first Does escaping the '{' solve the issue? :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc¹s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. From: Freeradius-Users <freeradius-users-bounces+stefan.paetow=jisc.ac.uk@lists.freeradius.org> on behalf of Dan Breslau <dbreslau@painless-security.com> Reply-To: "freeradius-users@lists.freeradius.org" <freeradius-users@lists.freeradius.org> Date: Friday, 26 May 2017 at 21:43 To: "freeradius-users@lists.freeradius.org" <freeradius-users@lists.freeradius.org> Subject: Recursive string expansion
I have an issue with recursive string expansion -- that is, it is recursing in a situation where I'd rather it didn't. Specifically, with freeradius 3.0.13, in policy.d/moonshot_targeted_ids, if I set
targeted_id_salt = '${changeme'
then I get the error:
Fri May 26 20:23:37 2017 : Error: /etc/freeradius/policy.d/moonshot-targeted-ids[40]: Reference "${changeme%{tolower}" not found Fri May 26 20:23:37 2017 : Error: Failed expanding section name Fri May 26 20:23:37 2017 : Error: /etc/freeradius/policy.d/moonshot-targeted-ids[41]: Failed allocating memory for section Fri May 26 20:23:37 2017 : Error: Errors reading or parsing /etc/freeradius/radiusd.conf
This seems to be a reference to these two lines (starting at line 40) :
if (&outer.request:GSS-Acceptor-Host-Name) { if ("%{echo:/usr/bin/uuid -v 5 ${policy.moonshot_host_namespace} %{tolower:%{User-Name}}${policy.targeted_id_salt}%{tolower:%{outer.request :GSS-Acceptor-Host-Name}}}" =~ /^([^ ]+)([ ]*)$/) {
So it definitely looks like ${policy.targeted_id_salt} is expanded once, and then something attempts to expand the expanded string, which fails because '${changeme' is invalid xlat syntax.
I haven't found any user documentation indicating whether string expansion is recursive. I did find an older post by Arran where he says that "rlm_sql does recursive xlat" (see (http://lists.freeradius.org/pipermail/freeradius-users/2009-April/037249. html). This makes me wonder whether this behavior is decided upon by the module's implementer.
If there is a way to prevent this behavior (i.e., force a string to be expanded non-recursively), I'd love to hear about it. I'd be happy to file a bug (or feature request) if that would be appropriate.
Thanks,
Dan Breslau
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 26, 2017, at 4:43 PM, Dan Breslau <dbreslau@painless-security.com> wrote:
I have an issue with recursive string expansion -- that is, it is recursing in a situation where I'd rather it didn't. Specifically, with freeradius 3.0.13, in policy.d/moonshot_targeted_ids, if I set
targeted_id_salt = '${changeme'
The ${...} syntax is for string expansion in the configuration files. It's really macro substitution, and not run-time expansion.
then I get the error:
Fri May 26 20:23:37 2017 : Error: /etc/freeradius/policy.d/moonshot-targeted-ids[40]: Reference "${changeme%{tolower}" not found
Yes, because it's trying to parse ${...} as a macro / reference, and it doesn't exist.
So it definitely looks like ${policy.targeted_id_salt} is expanded once, and then something attempts to expand the expanded string, which fails because '${changeme' is invalid xlat syntax.
Yes. See the use of ${...} everywhere else in the configuration files.
I haven't found any user documentation indicating whether string expansion is recursive.
It expands the strings you enter. If you have nested expansions, all strings are expanded.
If there is a way to prevent this behavior (i.e., force a string to be expanded non-recursively), I'd love to hear about it. I'd be happy to file a bug (or feature request) if that would be appropriate.
Escape the string, so that it doesn't try to do string expansion when you don't want it. Or, since the contents of the salt are unimportant, just use a long sequence of hex characters. And don't use characters which will cause string expansion. Alan DeKok.
On 5/27/2017 4:14 AM, Alan DeKok wrote:
On May 26, 2017, at 4:43 PM, Dan Breslau <dbreslau@painless-security.com> wrote:
I have an issue with recursive string expansion -- that is, it is recursing in a situation where I'd rather it didn't. Specifically, with freeradius 3.0.13, in policy.d/moonshot_targeted_ids, if I set
targeted_id_salt = '${changeme' The ${...} syntax is for string expansion in the configuration files. It's really macro substitution, and not run-time expansion.
Escape the string, so that it doesn't try to do string expansion when you don't want it.
Ah, but therein lies the rub. I know that I can escape the % character by doubling it. But I haven't seen a documented way of escaping a $; and neither $$ nor \$ works in my tests. I'm wondering if there's a way of escaping it that I might have missed. But I also see that 3.0.14 came out the same day I wrote the earlier email, and it seems that this issue has been addressed in a different way. So while I'm still curious about this, it's now more of a theoretical interest than a real (or potentially real) problem. Thanks, Dan
participants (3)
-
Alan DeKok -
Dan Breslau -
Stefan Paetow