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.