Re: ODBC & Client Access
Ray Riley wrote: > > Does anybody have an answer for ODBC client security? > > Once you open up ODBC to users, how do you keep them from modifying tables without the > benefit of applications enforcing the database integrity? > > Ideally, I should be able to monitor who connects via ODBC and control access to the > databases and tables without having to get involved with lots of messy grants and > revokes. I've read on this Newsgroup somebody mentioning a product/technique called > "Roles," but I haven't been able to find any reference to it elsewhere, but it is > supposed to help manage grants etc. Has anyone heard of, or have any info on this? > > I researched SPLs and triggers, but there doesn't seem to be a trigger event for users > connecting to the database. I could enforce access to be read-only if I were to trap > Insert Updates and Deletes, but I would really like to be able to monitor connections > to the database as well. > > All this runs under INFORMIX Online 5.x and Intersolv's DataDirect SequeLink. Any help > would be appreciated on this issue, post or direct e-mail. > > Much thanks, > Mike Sullivan > > PS: If anyone has heard of the read-only switch in SequeLink's .ini file, it has a > bug; it does not work. At risk of repeating a point I made some time ago, I believe there's a need to authenticate the application as well as the user. If you give users access to the datbase and a set of tables with GRANT they can, as things stand, access them with any program they get their hands on. There seems to be little to prevent a user stitching together visual basic or even a spreadsheet with ODBC and hitting the database with it. Providing what they do doesn't violate any defined constraints I don't see how you can lock them out. It seems to me that the ODBC mechanism ought to incorporate a digital signature from the application and that there ought then to be CRUD ermissions against application or application/user combinations. The present situation, as far as I can see, is a large security hole. Ian