Re: How to set user privivilge at the application level
Posted in 1999
Ben Check out roles. Give PUBLIC only select rights to the database, and create a role (call it appuser, for example) that allows full access. In your application SET ROLE appuser before doing any SQL calls. Of course, this still does not prevent a malicious user who knows his way around the database to figure out the ROLE and set it himself in his ODBC connection and then proceed to bash your database into nothingness :-). Also since I just noticed that you use an application based security module, it may be possible to do the above in the module itself, probably with more efficiency, since you can store the appuser username encrypted in the database and have your application decrypt it using a secret key in your compiled application. Still does not prevent the programmer who has access to your source code doing the database equivalent of cd /; rm -rf * on his last day at work :-). HTH Sujit PS - be afraid, be very afraid. Ben Truong <Ben.Truong@amd.com> on 09/10/99 10:48:20 AM Please respond to Ben Truong <Ben.Truong@amd.com> To: informix-list@iiug.org cc: (bcc: Sujit Pal) Subject: How to set user privivilge at the application level In our environment, we have an application that requires users have full access privileges (connect, update, delete, select, insert). The application has a security module that handles who can do what. This application runs on HP servers and we have control of the software and tools that make available to users. Increasingly, more and more desk top users with ODBC drivers are beginning to connect to our database directly. In addition to the queries and reports, these users can damage the database, maybe by accident. So what we need is the ability to discriminate the user accessing the database at the application level. i.e. if a user access the database from our application, the database will allow that user to have full access privileges, else it limits that user to do data query only. Many thanks to ideas, suggestions, etc. Ben Truong ben.truong@amd.com