Getting a string 'as is' with no escapes from LDAP

[Kostas Zorbadelos]

On Πεμ, Σεπ 13 2018 at 10:09:58 πμ, Alan DeKok <aland at deployingradius.com> wrote:

> On Sep 12, 2018, at 2:42 AM, Kostas Zorbadelos <kzorba at otenet.gr> wrote:
>> 
>> I think a new thread is better for this discussion. In a previous thread
>> (http://lists.freeradius.org/pipermail/freeradius-users/2018-September/092606.html)
>> I raised the issue of failing to get a string as is from an LDAP
>> backend. The string represents the clear text password and I would like
>> to take it 'as is' with no escaping of any kind.
>> 
>> I got the explanation about the shell rules that are now implemented in
>> freeradius 3 for strings, so as to get a single uniform approach to
>> freeradius 3 and fix the inconsistencies of string handling in
>> freeradius 2.
>
>   Yes.
>
>   Plus, we have no idea what's in the back-end database.  Are the
> strings "raw" and should be used as-is?  Or do the strings contain
> escaped characters?
>

You are correct, it could be both.

>   It's impossible to know in advance.  People want to use both types
> of data.  We try to have the server make the best choice, but it's
> just a guess.
>
>> Now, we found a problem for strings beginning with '0x' :)
>
>   Yes.  Some people want to be able to assign binary data to strings,
>   too.  So that syntax is supported. 
>
>   The question again is when and where it should be supported...
>
>> Is there a way to overcome this?
>
>   Come up with a solution that makes sense, works, and is simple for
>   people to use. 
>

I can only make a rough first proposal. In case of strings stored in a
backend DB (LDAP, RDBMS) that get mapped to radius attributes it would
be nice to let the admin declare the expected behavior.

For example we could use something in the attribute definition in the
dictionary to declare that values out of parsing of such an attribute
should be obtained in raw form. 

>> Generally speaking a solution is needed to get a string 'as is' out of
>> an LDAP backend (most probably this will affect other backends too)
>> without escaping/unescaping of any kind.
>
>   There's a lot more than that involved, unfortunately.
>

I can only guess the complexity. You fully grasp the code.

Should we move the discussion to the github issue? Do you think this is
a valid feature to have and work towards a solution?

Regards,
Kostas

PS: I am curious, doesn't anyone else store clear text passwords with
funny characters in backend DBs? As I said this used to work in
freeradius 2 ldap module.

-- 
Kostas Zorbadelos	http://gr.linkedin.com/in/kzorba