SQL Module: Inconsistent behavior dealing with the escaping backslash
Hi, 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. I will put more detail of the Case 2 log, below, $radiusd -X (0) server dynamic_client_server { ........... ........... rlm_sql (sql): Reserved connection (2) (0) Executing select query: SELECT secret FROM nas WHERE nasname = '192.168.99.1' rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 rlm_sql (sql): Released connection (2) (0) EXPAND %{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'} (0) --> test\123 (0) FreeRADIUS-Client-Secret = test\123 rlm_sql (sql): Reserved connection (3) ........... ........... (0) } # server dynamic_client_server (0) Converting control list to client fields (0) ipv4addr = 192.168.99.1 (0) secret = test\\123 (0) shortname = Radius Local Test (0) nas_type = other Adding client 192.168.99.1/32 with shared secret "test\\123" in bold, you will see the additional backslash has added when it is converting control list to client fields. However, in Case 1, It doesn't even print out the log from rlm_sql, So, I assume that it is adding the client information from a different path with the different logic. As a result, the client is added with shared secret test\123, in this case. Suppose, I want to set the read_clients option to be "no", as the shared secret can be modified at any time and it should be reflected at every request, why can't both cases have the same way of treating escaping backslash? Thanks! Best Regards, WJ ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
On Jan 25, 2018, at 12:30 PM, Kwak Wookjong <Wookjong.Kwak@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.
Hi Alan, Thanks for the respond and your suggestion. But I am still seeing the same problem. (Additional backslash prepended) Even though, using another table (other than NAS) for putting client information, When, putting the information into attributes, the additional step that you described would be applied. Then, it would make additional backslash in front of original backslash as it is not *directly* read from the table. My question would be how can I make the value read directly from the table as it does for NAS table reading? Or, do we need to check if the escaping is properly done when putting the information into attributes? Best Regards, WJ -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+wookjong.kwak=gemalto.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Thursday, January 25, 2018 12:09 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [+SPAM+]: Re: SQL Module: Inconsistent behavior dealing with the escaping backslash On Jan 25, 2018, at 12:30 PM, Kwak Wookjong <Wookjong.Kwak@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.
On Jan 25, 2018, at 2:10 PM, Kwak Wookjong <Wookjong.Kwak@gemalto.com> wrote:
Thanks for the respond and your suggestion. But I am still seeing the same problem. (Additional backslash prepended)
Even though, using another table (other than NAS) for putting client information, When, putting the information into attributes, the additional step that you described would be applied. Then, it would make additional backslash in front of original backslash as it is not *directly* read from the table.
My question would be how can I make the value read directly from the table as it does for NAS table reading?
You can't. You MUST put the value into an attribute. That's how the dynamic clients work.
Or, do we need to check if the escaping is properly done when putting the information into attributes?
You need to ensure that the contents of SQL are correct. Which means escaping things properly. Backslashes are special, because they allow escaping. If you want a literal backslash, put "\\" into SQL. Then when you read it from SQL via a SELECT statement, it will be parsed correctly. If this isn't clear, post the *debug output* of the server when it reads a dynamic client from SQL. That will be much clearer. Alan DeKok.
participants (2)
-
Alan DeKok -
Kwak Wookjong