Re: Can oninit be run from a shell?

Jonathan Leffler wrote: > > Valery Fouques (valou@hotmail.com): > }X-Informix-List-Id: <news.36494> > } > }There is one solution for what you want: > }Change ouy shell's owner and group to informix:informix > }and issue a chmod +s on your shell (sticky bit). > }Then, anyone executing your shell will be given informix's identity (and > }will have the rights to execute oninit...) > > Valery, > > That is not a solution -- it is a catastrophe waiting to happen! > > You must, must, MUST, control who can do what with the informix login. > > Otherwise, anybody can take the OnLine system off-line at any time, or > delete swathes of data, or otherwise completely break the system. > > Yours, > Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> > > }Jonathan Leffler <johnl@informix.com> wrote: > }> No, normally root or informix runs it; your system seems to have been > }> installed with role separation enabled so that it is the DBSA (database > }> administrator) who has to do it. > }> > }> }From: nws@stout.atd.ucar.edu (Eddie Roberts) > }> }Date: 10 Apr 1997 18:59:12 GMT > }> }X-Informix-List-Id: <news.36420> > }> } > }> }Is there anyway a "normal - non priveledged" user can run oninit from > }> }a shell script? [...] > }> } > }> }BUT, I get the following error message: > }> } "Must be a DBSA to run this program" Some systems will not allow suid on shell scripts. But, any usage of suid you must be very careful about. Our solution to avoid most security loopholes for this type problem was a compiled program that you would setuid to root/informix and pass the command line you wanted (to execute the shell). The program checked the first parameter in a table to make sure it was an approved command, check to see if you were an authorized user of that comand, and verified that the setuid was the proper one for that command (if not and it was root, it should really suid to the proper user, but that feature was not installed). If a flag was set in a control file, the executed command must have suid & ownership set correctly to make sure that the destination command was not comprimised (I usually took execute permission away from all others as well). We've used this for several accesses where we wanted more control of who could get in and reducing the size of the loopholes. Our implementation used compiled tablesm plans were included to later load from a file (watching permissions there) but that was not installed. I'm not sure of exact features of sudo which I saw referenced in another article. S.W. -- wilcoxon@pioneerplanet.infi.net ********************************************************************** ... this is only a test ... if this had been a real signature it would have been interesting **********************************************************************