Re: Database security

Path: emory!swrinde!cs.utexas.edu!wupost!udel!brahms.udel.edu!god From: god@brahms.udel.edu (Scott C Gray) Newsgroups: comp.databases.informix Message-ID: <25006@brahms.udel.edu> Date: 13 Oct 91 17:12:28 GMT References: <503@rand.mel.cocam.oz.au> <1991Oct12.215926.9788@informix.com> Organization: University of Delaware The setuid() option which has been mentioned several times only works to a certain extent. To give an example: For the last several months I have been working on a utility to supply class (or group) priviledges to informix. This program allows user accounts to be added to machines in groups...for example, when adding a data entry person to the system the program: 1. Creates a login in /etc/passwd and an entry in /etc/group 2. Copies the proper .profile or .login into their directory 3. Grants the proper permissions on all of the tables required for the applications they are to run. 4. Installs them in yp. To get around the problem of isql, we simply do not allow them to run it unless we trust them with the data. When granting permissions I just have the program setuid to the owner of the tables then grant the permissions. Unfortunatly when it comes time to revoke permissions on a user this method doesn't work because on revokes informix doesn't look at the uid...it looks at the login name of the person running my program. After much agrivation and hours of sitting on hold with informix's "hotline" we finally came to the conclusion that we had to delete directly from systabauth. I no-no in my book, but it had to be done. Anyway, it worked. Anyway, if anyone finds a workaround for this or a future extension to informix, let me know...It would save me a lot of agrivation. later... - Scott