SQL Module: Inconsistent behavior dealing with the escaping backslash

[Alan DeKok]

On Jan 25, 2018, at 12:30 PM, Kwak Wookjong <Wookjong.Kwak at gemalto.com> wrote:
> I have found that the backslash in the shared secret interpreted differently
> depending on the read_clients option to be set in the /etc/raddb/mods-enable/sql
> 
> Case 1.
> When the DB is read while its startup only, by setting read_clients option to be yes,
> for example, the shared secret, test\123 is read as test\123 and the client is added
> with having single backslash.
> 
> Case 2.
> When the DB is read per each request, by setting read_clients option to be no,
> the shared secret, test\123 becomes test\\123 and the client is added
> with having double backslashes.

  That's an issue, but a minor one.  When "read_clients = yes", the clients are read *directly* from the NAS table.

  i.e. the information about the clients is not put into an attribute first.

  When you create clients manually, you're putting the information into attributes.  So there's an additional step  which is being taken.

  The short answer is that you should not dynamically pull client information from the nas_table, and put it into attributes.  The nas_table is intended to be used only when "read_clients = yes".

  If you do need dynamic clients, put their information into another table.

  i.e. each table has a specific purpose, and shouldn't be used for anything else.

  Alan DeKok.