On 17 Jun 2013, at 19:19, Alan DeKok <aland@deployingradius.com> wrote:
Arran Cudbard-Bell wrote:
I have to agree. If an attribute doesn't exist then it should expand to "", that's the behaviour i'm used to too.
For me, it's a major security issue. Silently missing an attribute is bad.
I guess for things like command line arguments, yes, it would be. If it's a security issue arguably the entire expansion should fail, and we should force the user to deal with cases where an attribute may be NULL by specifying alternative static values. In a rather contrived case you could have someone using a shell script to verify an unsupported type of hash. They pass /bin/mysuperhash %{sql:SELECT user FROM users WHERE username='%{User-Name}'} %{Hashed-Password-Attribute} Username isn't found. /bin/mysuperhash _ 0x1111111111 Anywhere that wants to expand config:Cleartext-Password would have the same issue. If it's not going to be null string it shouldn't be anything else either. I don't see this as a usability issue because in the majority of cases an '_' isn't going to be what the admin wanted either.
Previously the xlat code wrongly treated zero length expansions as errors, this might of been the original reason for returning a one char expansion.
No, the zero-length expansion issue was a temporary problem during the re-write of the new code.
No, in a bunch of places radius_xlat()! was treated as an error. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team