Hi all, We are running FreeRADIUS 1.1.6 on Solaris 10 (sparc) and want to retrieve authorization information from an Pervasive SQL database via an ODBC Bridge. In order to do so we installed on our Solaris host: - the unixODBC ODBC Manager 2.2.12 - Easysoft ODBC-ODBC Client 32bit for Solaris
But every time a RADIUS request was processed and a valid SQL query was send via module rlm_sql_unixodb to the SQL database, both RADIUS and the remote ODBC server crashed. Error in radiusd: memory allocation. It took quite some debugging to find the cause of this. In the driver rlm_sql_unixodbc, in file sql_unixodbc.c we found the following code: =============== static int sql_num_fields(SQLSOCK *sqlsocket, SQL_CONFIG *config) { rlm_sql_unixodbc_sock *unixodbc_sock = sqlsocket->conn; long err_handle; int num_fields = 0; err_handle = SQLNumResultCols(unixodbc_sock->stmt_handle,(SQLSMALLINT *)&num_fields); if (sql_state(err_handle, sqlsocket, config)) return -1; return num_fields; } =============== SQLSMALLINT is defined in unixODBC, file: include/sqltypes.h typedef signed short int SQLSMALLINT; But num_fields is of type 'int' ! This caused the function to return 0x20000 instead of 0x001, which in turn caused both the radiusd and the remote ODBC server to allocate memory for 0x20000 (131072) rows! I simply changed this piece of code to: =============== static int sql_num_fields(SQLSOCK *sqlsocket, SQL_CONFIG *config) { rlm_sql_unixodbc_sock *unixodbc_sock = sqlsocket->conn; long err_handle; SQLSMALLINT num_fields = 0; err_handle = SQLNumResultCols(unixodbc_sock->stmt_handle,&num_fields); if (sql_state(err_handle, sqlsocket, config)) return -1; return num_fields; } =============== This solved our crashes. So the solution only involved changing the type of num_fields to SQLSMALLINT (the same as required by the SQL call SQLNumResultCols) and removing the type cast in the actual call to SQLNumResultCols (unnecessary now). After we solved it this way, I found the same error fixed in a similar way on a SUSE distribution list: http://lists.opensuse.org/opensuse-commit/2007-05/msg00099.html I believe this to be a small error in the rlm_sql_unixodbc Driver. Hopefully other people can benefit from our experience. Can anyone confirm that my solution is correct and should work for all OS's (as I expect) even though this might not cause problems on all OS's (as on some, a short int is just as big a normal int)? Then I will send in a bugreport via the site. Kind regards, Erik Plaggenmarsch
ÿþD i t b e r i c h t i s v e r t r o u w e l i j k e n k a n g e h e i m e i n f o r m a t i e b e v a t t e n e n k e l b e s t e m d v o o r d e g e a d r e s s e e r d e . I n d i e n d i t b e r i c h t n i e t v o o r u i s b e s t e m d , v e r z o e k e n w i j u d i t o n m i d d e l l i j k a a n o n s t e m e l d e n e n h e t b e r i c h t t e v e r n i e t i g e n . A a n g e z i e n d e i n t e g r i t e i t v a n h e t b e r i c h t n i e t v e i l i g g e s t e l d i s m i d d e l s v e r z e n d i n g v i a i n t e r n e t , k a n A t o s O r i g i n n i e t a a n s p r a k e l i j k w o r d e n g e h o u d e n v o o r d e i n h o u d d a a r v a n . H o e w e l w i j o n s i n s p a n n e n e e n v i r u s v r i j n e t w e r k t e h a n t e r e n , g e v e n w i j g e e n e n k e l e g a r a n t i e d a t d i t b e r i c h t v i r u s v r i j i s , n o c h a a n v a a r d e n w i j e n i g e a a n s p r a k e l i j k h e i d v o o r d e m o g e l i j k e a a n w e z i g h e i d v a n e e n v i r u s i n d i t b e r i c h t . O p a l o n z e r e c h t s v e r h o u d i n g e n , a a n b i e d i n g e n e n o v e r e e n k o m s t e n w a a r o n d e r A t o s O r i g i n g o e d e r e n e n / o f d i e n s t e n l e v e r t z i j n m e t u i t s l u i t i n g v a n a l l e a n d e r e v o o r w a a r d e n d e L e v e r i n g s v o o r w a a r d e n v a n A t o s O r i g i n v a n t o e p a s s i n g . D e z e w o r d e n u o p a a n v r a a g d i r e c t k o s t e l o o s t o e g e z o n d e n . T h i s e - m a i l a n d t h e d o c u m e n t s a t t a c h e d a r e c o n f i d e n t i a l a n d i n t e n d e d s o l e l y f o r t h e a d d r e s s e e ; i t m a y a l s o b e p r i v i l e g e d . I f y o u r e c e i v e t h i s e - m a i l i n e r r o r , p l e a s e n o t i f y t h e s e n d e r i m m e d i a t e l y a n d d e s t r o y i t . A s i t s i n t e g r i t y c a n n o t b e s e c u r e d o n t h e I n t e r n e t , t h e A t o s O r i g i n g r o u p l i a b i l i t y c a n n o t b e t r i g g e r e d f o r t h e m e s s a g e c o n t e n t . A l t h o u g h t h e s e n d e r e n d e a v o u r s t o m a i n t a i n a c o m p u t e r v i r u s - f r e e n e t w o r k , t h e s e n d e r d o e s n o t w a r r a n t t h a t t h i s t r a n s m i s s i o n i s v i r u s - f r e e a n d w i l l n o t b e l i a b l e f o r a n y d a m a g e s r e s u l t i n g f r o m a n y v i r u s t r a n s m i t t e d . O n a l l o f f e r s a n d a g r e e m e n t s u n d e r w h i c h A t o s O r i g i n s u p p l i e s g o o d s a n d / o r s e r v i c e s o f w h a t e v e r n a t u r e , t h e T e r m s o f D e l i v e r y f r o m A t o s O r i g i n e x c l u s i v e l y a p p l y . T h e T e r m s o f D e l i v e r y s h a l l b e p r o m p t l y s u b m i t t e d t o y o u o n y o u r r e q u e s t . A t o s O r i g i n N e d e r l a n d B . V . / U t r e c h t K v K U t r e c h t 3 0 1 3 2 7 6 2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html