xlat expansion of absent VPs

[Arran Cudbard-Bell]

On 17 Jun 2013, at 19:19, Alan DeKok <aland at 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 at freeradius.org>
FreeRADIUS Development Team