Re: ODBC with informix

Hi Glyn Openlink provides two methods of security against connections WIth Opsys login turned on, any user making a connection to the database will be checked against the Operating system password file. If the user is valid, then access will be granted. Alternatively, you can restrict access to specific users even if they ass the Opsys login test. Openlink provide an ini file situated on the server which can be manipulated to restrict access. You can create diferent environmets for your Users. For instance, User A, B, and C will have full rights and User D and E can be restricted to a Read-only connection. You can also restrict the users that come in from paricular application e.g. Excel or create Aliases that. This is without doubt one of the best features of Openlink and if you want to evaluate this, please visit www.openlink.co.uk for a 2user 10 connection non-expiry copy. Hope this resolves your problem Best Regards Emmon Simbo Openlink Software 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