Re: ODBC with informix

Glyn, This problem has been addressed often before with no really elegant solution. The essence of the problem is that security mechanisms are programmed into the application(s) while ODBC enables users to bypass this security and access the database directly. Perhaps the only pure solution is to build the security into the database (triggers and such) but this is impractical in most cases. My current favorite solution works and is as follows: 1. Create a special role with an unusual name and keep it secret from your users, like a password. 2. Give the role full access to the database. Give the users only the privileges they need for ad hoc ODBC access. Grant the appropriate users access to the secret role. 3. Put a "set role" command to the secret role in the applications that require full access to the database. If the application is developed by a third party then I don't know what you can do. You could look into openlink odbc drivers that have some security features built in but I don't know if they're available for NT servers (see http://www.openlink.com). Best of luck, ---------------------------------------------------------------------- John H. Frantz Power-4gl: Extending Informix-4gl john@rl.is http://www.rl.is/~john/pow4gl.html Glyn_Balmer_at_erith@smtpgwy.supertension.com wrote: > > Matt Reprogle wrote : > > > Jay Hannah wrote: > > > > > > Killspamrs wrote: > > > > Along this line, but completely different, in an NT/win 95 > > environment is it possible to completely disable all ODBC > > connectivity from within Informix? I > > > <snip!> > > > Since syscolsauth will say they have add/change/delete god knows > what they > > could do. > > > > If you don't trust these users w/ delete/mod access, why do they > > have it in the first place? Revoke priviledges in Informix, and > > they're locked > > out no matter what client (ODBC or otherwise) they use. > > > Have I missed something? > > > > Jay > > > Perhaps. In some situations, users have an "approved" application > > through which they are allowed to perform modifications, but you do > > not want them to have unrestricted SQL-level access through > > ODBC-enabled tools like MS-Query. > > Agreed. We admininster a package wherein the end user requires all > permissions on all tables in order to be able to carry out their > normal job function. However, we also need to give ODBC access to > certain individuals to enable database access via MSOffice, for > example. Therein lies our quandary. Since the user has a pukka (UNIX) > login to the database with full permissions, how do we prevent him/her > attaching via ODBC as the same user and thereby open the flood gates ? > > At the present moment in time this is still an unresolved problem to > us. > > Regards > > Glyn Balmer > I.T. Consultant > BICC Cables Limited > Erith Kent UK