bhave@hpcmsrb.HP.COM (Nitin Bhave) (02/01/89)
I have a question concerning Informix access/permissions. We require that certain tables in our database be modified only by a fixed set of 4GL or ESQL/C programs. These programs will be owned by a single login name and also only this same login name will have insert/update permission on these tables. But other users should be able to run these programs ( or modify the tables via these programs ). In other words we don't want to give all the users the capability of modifying these tables through interactive SQL or through their own programs. Setting the setuid bit doesn't help because Informix apparently gets the real uid ( rather than the effective uid ) to determine table access. Is there any way I can implement the above scheme ? Thanks in advance. Nitin Bhave CMS Hewlett Packard Palo Alto, CA 94304 (415)857-5772 email: bhave%hpcmsa@hplabs.hp.com
john@riddle.UUCP (Jonathan Leffler) (02/20/89)
In article <12460001@hpcmsrb.HP.COM> bhave@hpcmsrb.HP.COM (Nitin Bhave) writes: >We require that certain tables in our database be modified only by >a fixed set of 4GL or ESQL/C programs. These programs will be owned by >a single login name and also only this same login name will have insert/update >permission on these tables. But other users should be able to run >these programs ( or modify the tables via these programs ). >Is there any way I can implement the above scheme ? Yes, but it involves a SUID root program. To explain: Diagnosis: Your observation that Informix uses the real UID to determine database permissions is correct. Whenever a user accesses a database, they fork off a copy of $INFORMIXDIR/lib/sqlexec which is responsible for handling the database. It is SUID root, SGID informix. When it starts up, it does some things that only root can do (notably kick ulimit out of sight so that it can create large database tables) and then resets its effective UID back to the only other UID it has, namely the real UID. Thus, if a SUID anybody program tries to access a database, the SUID anybody property is lost and Informix uses the real UID of the person who ran the program to control access to the database. (BTW: because sqlexec rests the UID, all database access is normally handled via the GID informix permissions.) Prescription: So much for the diagnosis; what can you do about it? The description above ignores the special properties of a SUID root program. The relevant special property is that when the effective UID of a process is 0 (root) and the program executes setuid(2), both the real and effective UIDs are set (for anyone else, only the real UID is set, and it can only be set to the real UID). This means that you could right a SUID root program which did a lookup in /etc/passwd for the user name of your privileged user (getpwnam(3)), and then reset the UID to that value. You would then execute one of your programs that would have been SUID privileged. Be very careful about SUID root programs. They must not be writeable, and the directory they are contained in should not be generally writeable either. I would suggest that you kept some sort of table which described who could do what; this might be a plain text file, or coded into the SUID root program, or even part of the database if you don't mind the overhead of starting two lots of sqlexec and you ensure that you close the file descriptors to the sqlexec used to check the permissions before executing the program that is intended to do the work. You have to do this checking before the setuid(2) call, because after that you have lost any trace of who it was who invoked the SUID root program. Jonathan Leffler (john@sphinx.co.uk)