Re: HELP : preventing users from escaping to shell (!sh)
Posted in 1995
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL
[I have taken the liberty of crossposting to comp.databases.informix, as the readers there may be interested and/or have further comments] In article <hM8fGY+.meyer412@delphi.com>, Richard Meyer <meyer412@delphi.com> wrote: > The Unix system we are using at work has a security problem. We have a > class of user which requires access to the Informix database. Informix allows > the users to escape to the shell. We don't want this. Informix suggested > setting the users shell variable to "" and exporting that before invoking > the application. > > This only works if the application does not try to invoke another shell. > In that case the application does not work properly. I've played around with > different variations of this solution, but to no avail. > > Has anybody solved this problem before? If so what is the solution? I assume your applications are Informix-4GL, since you mention them trying to invoke another shell. Our solution was as follows: 1: set $SHELL to an empty string in the users' profiles 2: write our our rsystem() function [int rsystem(char*)] to replace Informix's in the 4gl library. The 4GL "RUN" statement translates to a call to rsystem(), and our rsystem() guarantees that /bin/sh instead of $SHELL is used to run the command passed to it as an argument. You may be able to have rsystem() simply call system() to achieve this. The programmer can then use RUN like normal, and it will always work. Alternatively give this function a new name and change all your existing 4gl RUN statements to be calls to this function. 3: write a shell escape function which should be used in place of the RUN statement in 4gl when the programmer wants to allow access to the shell conditional on the value of $SHELL. eg for implementing ! escapes in menus. This function probably can't use system() but would do the fork()/exec() shuffle. If you never want real shell escapes, or if you use the alternate version of step 2, then skip this. I leave implementation of the above as an exercise for the reader. -- Hugh Grierson hugh@fujitsu.co.nz Nuke Chirac