RE: Running Utilities as anothe

John, I understand your concern. I truly believe that this program will provide the answer you are searching for. The password is NOT exposed, and the user is not able to su to informix at any time. That actually is why I wrote the program instead of using "sudo", because sudo allows a user to become superuser for some period of time. The program in question can be used as a replacement for any of the Informix utilities. As an example, let's consider ontape. The su_ontape executable is owned by informix and has the setuid flag set, so permissions are ----s--x--x. When the user wants to perform a backup, they just type in "su_ontape -s -L 0". The program then checks to make sure that a few environment variables are correctly set. It then checks the command line parms against a list of allowable options, which you can change to suit your needs. For instance, you probably don't want this user to perform an "ontape -r". After this, the program performs the "su informix", then immediately performs an execv() to load $INFORMIXDIR/bin/ontape directly on top of itself, passing the command line args. At no time is the informix password required, not even in the program source. Even if you change the informix password and tell no one of the new password, this program still works. I have created a script which allows our operations staff to perform ontape archives of our production database without knowing the informix password. When that script is running, if you do a "ps -ef | grep ttyxx" for the terminal they are running on, you see the following: mcollins 20813 20812 0 08:46:03 ttyp7 0:00 ksh informix 21911 20813 0 10:03:09 ttyp7 0:00 /usr/informix/bin/ontape -s -L 0 As soon as the ontape command completes, process 21911 goes away, and with it go the rights of user informix. Now, unless your user knows of some way to steal that child session and change what it is executing, I believe that this provides adequate protection. Note that even if he were to switch the ontape process to the background, the parent process (20813) has his id, thus he could not accidentally inherit more power than he should have. If you are still hesitant about this alternative, just take a look at the program. The source is available at http://www.iiug.org, in the software archive under Database Administration utilities, named su_ontape. After you look at it, feel free to contact me for any questions. Mark Collins mcollins@us.dhl.com =============================================== The problem I have with this solution is that either the password will be exposed, or the user will be able to su to informix at any time. The user of this tool is able to log on to unix and has just enough knowledge to do some damage by su'ing to informix. Thanks for the suggestion, but I"m looking for a different way. JP