HELP : PREVENTING USE
Posted in 1995
H> From: hugh@nezsdc.fujitsu.co.nz (Hugh Grierson) H> 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. Informix (4gl) does not allow escape to the shell automatically, this must be built in by the programmer. Usually, this is done by a piece of code similar to: MENU COMMAND KEY ("!") CALL escape_to_shell() ... FUNCTION escape_to_shell() DEFINE command_line CHAR (80), x CHAR (1) IF NOT ok_to_shell() THEN RETURN END IF PROMPT "! " FOR command_line IF int_flag THEN LET int_flag = 0 RETURN END IF RUN command_line PROMPT "Press [ENTER] to continue." FOR CHAR x END FUNCTION Note that there are two ways you can control user shell access using this example or a variation. First, the ok_to_shell function (not listed here, but which returns true or false) would decide if the user can shell out. This could be based on logins, values in tables, parameters passed as arg_val's, etc. Second, and more simply, you can remove the PROMPT logic from above and simply RUN "su". This forces the user to know the root password to get a shell. This may not be what you want, and it has the side effect of putting a user a root level, where things can happen accidentally. Also, su is not portable to a DOS world. Finally, you could invoke an rsh. However, rsh is so restrictive I have found it good for nothing. In my executables I chose the "su" method, since I designed the shell escape as a convenience for me when supporting the user. It was never intended to give my users shell access, since they never worked off the command line. --- ~ SPEED 1.40 [NR] ~