xlat expansion of absent VPs

[Phil Mayers]

On 18/06/13 23:56, Arran Cudbard-Bell wrote:
>
>>>> As far as I'm concerned, the *only* thing FreeRADIUS needs to
>>>> do is properly quote the variables it expands into a SQL query,
>>>> which it already does.
>>>
>>> OK. Then the default substitution should probably only be done
>>> for certain modules where it is an issue.
>>
>> I think that would be confusing.
>>
>>>
>>> On the command line blank arguments do affect programs which use
>>> positional arguments as multiple chars of whitespace are
>>> condensed.
>>
>> You've lost me. On the command line, that's done by the shell, and
>> if people using shell want to preserve whitespace, they must quote
>> appropriately.
>
> Yes, isn't that the security issue were talking about here? Where
> people don't appropriately quote xlat expansions and then something
> expands to a zero length string? At least in the context of exec.

Just to be clear, I don't think this is, or could be, a security issue. 
It simply generates an empty argument, which as I've said is both legal 
and not uncommon.

>
> If it's known that attributes are sometimes not included in the
> Access-Requests, then they can be marked as optional with
> %{%{Attr}:-}, if they're not marked as optional then the server is
> dealing with RADIUS packets the policy/server configuration was not
> designed to process, and should fail closed. It should not invent
> values.

It's not inventing a value. It's defining a value to which the "absent" 
attribute expands in a string, in exactly the same way that it defines 
how attributes of type "octets" expand to 0xHEX or similarly for other 
types.

You seem to be saying that the server should define "absent" attributes 
should convert the whole xlat into the empty string + error code.

I disagree, but to be honest we're going round in circles here, and I 
don't think this discussion is contributing much.

Do what you think best.