On Πεμ, Σεπ 13 2018 at 10:09:58 πμ, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 12, 2018, at 2:42 AM, Kostas Zorbadelos <kzorba@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...) 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