ODBC Security
Tracy Sweeney asked how to stop users from bypassing application record-level security through ODBC, and whether an onipcshm link would prevent it. Chuck Renaud suggested views. Obnoxio The Clown suggested revoking table permissions and allowing access only through stored procedures. Preetinder Dhaliwal described a setuid wrapper mapping user ids. No single answer was confirmed.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Consider this scenario: An ODBC connection configured to allow a user direct access to a database, thus bypassing any application security locking users out from specific records of tables. Any user granted access to a table is granted access to the table level, although when running programs, are locked out of specific records. An ODBC connection allows the user to bypass the security of the application. Consider creating a separate database server and application server, configured on a separate private network connection. So, when the users log onto the system they log onto the application server and they only access the data on the database server via the onsoctcp (or ontlitcp) connections over to the database server. Wouldn't the end user still be able to create an ODBC connection to the application server, using the information from the sqlhosts file to access (and possibly change) data in the tables on the database server? OR can we create an onipcshm connection between the application server and the database server which would not allow the user to access the data via an ODBC? Is there any easy way to ensure that users that are supposed to have limited access to the data via an application cannot access the data with an ODBC? Any thoughts/ideas and direction are greatly appreciated.
> Is there any easy way to ensure that users that are supposed to have > limited access to the data via an application cannot access the data > with an ODBC? Views?
Personally, I'd have said "revoke all table permissions and only allow access via stored procedures". -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" - Coluche >From: "Chuck Renaud" <chuckr@pobox.com> >To: ids@iiug.org >Subject: Re: ODBC Security [820] Date: Fri, 28 Mar 2003 14:56:26 -0500 >(EST) > > > Is there any easy way to ensure that users that are supposed to have > > limited access to the data via an application cannot access the data > > with an ODBC? > >Views? > > _________________________________________________________________ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile/mobilehotmail
There is one messy way of doing so, Write a c program which is suid root and will change user to another user which has a database connect(setuid function). Maintain a mapping of id->id1 somewhere and change the id to new id before connecting to application( make a wrapper around ur application). This way the normal userid's will not have connect to the database and will not be able to access through ODBC. Rgds Preetinder "Obnoxio The...." wrote: > Personally, I'd have said "revoke all table permissions and only allow > access via stored procedures". > > -- > Bye now, > Obnoxio > > "C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule" > - Coluche > > >From: "Chuck Renaud" <chuckr@pobox.com> > >To: ids@iiug.org > >Subject: Re: ODBC Security [820] Date: Fri, 28 Mar 2003 14:56:26 -0500 > >(EST) > > > > > Is there any easy way to ensure that users that are supposed to have > > > limited access to the data via an application cannot access the data > > > with an ODBC? > > > >Views? > > > > > > _________________________________________________________________ > On the move? Get Hotmail on your mobile phone > http://www.msn.co.uk/msnmobile/mobilehotmail