Re: Restricting ODBC access

Jacob Salomon <jake@garpac.com> wrote in article <34E224B1.33FF130C@garpac.com>... > Hi Family. > > I have a client with a serious concern. > > Say I (jake) am a regular end user - when I log in to my Unix box, I > fall into a captive session, the application's main menu (no shell). In > this way I can hit at the database only through the application. BTW, > database access happens to be through a shared memory connection, > although I suppose socket access should also be set up for this system. > > Now I get clever - the greatest nightmare of an operations manager. I go > back to my PC and access the database via an Excel spreadsheet with > ODBC. I run a query and get the results in my sheet. I then update some > rows in the sheet (for what-if analysis - innocent) and inadvertently > save the data back to the database. > > Whoops! I have just messed with some data without going into the > application. > > Can anyone come up with a way to prevent database access via ODBC? I > can't simply deny ODBC drivers to all PC users - there are other > databases to be accessed. The restriction I need should be settable on > a database by database basis. (Say that fast 10 times. ;-) Ideally, it > should be able to restrict data modifications via ODBC. > <snip> Normally with Informix ODBC drivers you will have to set up a socket connection to the server. Once this is done, anyone with the Informix ODBC drivers on their PC and a Unix log in will be able to connect to the database with whatever permissions are associated with their log in. If you use a server based ODBC product such as OpenLink, you can avoid the socket connection. The OpenLink server piece will talk to Informix through the shared memory connection. Thus the only way to the database over the network will be through OpenLink. The OpenLink request broker on the server has a configurable rule book that will allow you to restrict access by user, host (client), application, database, client O/S, etc. The one caveat here is that is fairly easy (using something like MS Access) to change the name of the "application", so this should not usually be relied upon as airtight. Assuming you have NO ODBC applications which need R/W access for the users you are worried about, you can make things pretty tight by restricting EVERYONE, from every machine using every application to read only (or no) access. Then enable R/W access for those users you "trust". The possible combinations are numerous. HTH Irwin Goldstein Objective Software Systems, Inc. http://www.objectsoft.com Remove anti-spam characters from e-mail address when replying.