Re: dbaccess Permissions -- scenarios, unproven

Cathy, While this is not an answer, we've been wrestling with the same problems and have been talking about alternatives. We don't have a solution mapped out yet, or even know if the ideas are workable. But, we have discussed some ideas that may provoke thought. I would be interested in any other replies you may get. Here's some: 1) (Like your #2.) Only the stored procedures are written to do the updates. The users only have read access to the tables and execute access to the stored procedure. The stored procedures can (I understand) have update access to the tables even though the users who execute them don't. Disadvantages: that's a whole lot of stored procedures to write. It also means changing the application(s). Advantages: most security with no holes that we have been able to see. (I've seen a couple of variations of this on the list before.) 2) Have a set of IDs for each user. Example: usr001ro and usr001. When the user signs on the Unix box directly, then a UNIX script executes which changes his userid to a 'read-only' id. When the user signs on using PB or whatever, the script won't execute and the user has update capabilities. The negative to this is the fact that you have to have two IDs for each user. This can be difficult to manage without some kind of script or home-grown program to maintain security consistency for both the UNIX IDs and the database/table privileges. (I've saw this on the list a few months back, also.) This may not be feasible because a user could get a query tool that would use I-NET to talk to the database thus bypassing the UNIX script. If that happens, the user would use the usr001 permissions and could do all sorts of damaging inserts, deletes, changes outside the application's control. ***This could be a security hole in scenario number 1 listed in your message.*** This could be effective if only TELNET and RLOGIN sessions need to be restricted. The tricky part of all this is due to the theory that I-NET doesn't have a user exit where you can test where it originated in order to determine whether the user should be allowed to continue. I guess that would be ideal. If the I-NET came from your application, then all's well. If not, then the connection would be refused. The UNIX script would take care of all logins not through I-NET. I guess this is a variation on #2 above, but it depends on a nonexistent feature. anyone else try to tackle this one?????? donald_boothby_at_isdlan@ima.isd.state.in.us (317)232-4602 Don Boothby (DBA) State of Indiana - ISD Room N551, IGCN 100 N Senate Ave Indianapolis, IN 46204 "Home of the longest email addresses I've seen" ______ Reply Separator ______ Subject: dbaccess Permissions Author: ckipp@vth1.vth.colostate.edu (Cathy Kipp) at IMA Date: 5/23/95 1:58 Folks, I know it is not generally considered a good idea to change Unix file permissions on Informix files, but I do have a problem I think this change would help me with anyway, or maybe you all have a better solution. Problem: User A has been granted a wide variety of permissions to Informix tables and databases because the user runs applications which require these permissions. However, if User A were to become a more advanced user, he/she could easily execute dbaccess from the Unix command line and create all sorts of havoc by inserting, updating, and deleting data which I really don't want them touching except through an application program. (This is becoming as issue since users now have access to Unix where before they were confined to menus.) Potential Solutions: 1) Change dbaccess permissions from: -rwxr-xr-x informix informix to: -rwxr-x--- informix infmx_user where the group infmx_user includes only the half dozen people who have any business executing this program. At the moment this is my preferred solution. Are there any problems with this scenario I am missing? 2) Write a set of stored procedures which are executed as dba to grant and revoke privileges every time a user enters or exits a program. I really don't think this is a very efficient thing to do and I would prefer to avoid it. <snip>