4.7)  How can I get setuid shell scripts to work?

      [ This is a long answer, but it's a complicated and frequently-asked
        question.  Thanks to Maarten Litmaath for this answer, and
        for the "indir" program mentioned below. ]

      Let us first assume you are on a UNIX variant (e.g. 4.3BSD or
      SunOS) that knows about so-called `executable shell scripts'.
      Such a script must start with a line like:

        #!/bin/sh

      The script is called `executable' because just like a real (binary)
      executable it starts with a so-called `magic number' indicating
      the type of the executable.  In our case this number is `#!' and
      the OS takes the rest of the first line as the interpreter for
      the script, possibly followed by 1 initial option like:

        #!/bin/sed -f

      Suppose this script is called `foo' and is found in /bin,
      then if you type:

        foo arg1 arg2 arg3

      the OS will rearrange things as though you had typed:

        /bin/sed -f /bin/foo arg1 arg2 arg3

      There is one difference though: if the setuid permission bit for
      `foo' is set, it will be honored in the first form of the
      command; if you really type the second form, the OS will honor
      the permission bits of /bin/sed, which is not setuid, of course.

      ----------

      OK, but what if my shell script does NOT start with such a `#!'
      line or my OS does not know about it?

      Well, if the shell (or anybody else) tries to execute it, the OS
      will return an error indication, as the file does not start with
      a valid magic number.  Upon receiving this indication the shell
      ASSUMES the file to be a shell script and gives it another try:

        /bin/sh shell_script arguments

      But we have already seen that a setuid bit on `shell_script' will
      NOT be honored in this case!

      ----------

      Right, but what about the security risks of setuid shell scripts?

      Well, suppose the script is called `/etc/setuid_script', starting
      with:

        #!/bin/sh
        
      Now let us see what happens if we issue the following commands:

        $ cd /tmp
        $ ln /etc/setuid_script -i
        $ PATH=.
        $ -i

      We know the last command will be rearranged to:

        /bin/sh -i

      But this command will give us an interactive shell, setuid to the
      owner of the script!
      Fortunately this security hole can easily be closed by making the
      first line:

        #!/bin/sh -

      The `-' signals the end of the option list: the next argument `-i'
      will be taken as the name of the file to read commands from, just
      like it should!

      ---------

      There are more serious problems though:

        $ cd /tmp
        $ ln /etc/setuid_script temp
        $ nice -20 temp &
        $ mv my_script temp

      The third command will be rearranged to:

        nice -20 /bin/sh - temp

      As this command runs so slowly, the fourth command might be able
      to replace the original `temp' with `my_script' BEFORE `temp' is
      opened by the shell!  There are 4 ways to fix this security hole:

        1)  let the OS start setuid scripts in a different, secure way
            - System V R4 and 4.4BSD use the /dev/fd driver to pass the
            interpreter a file descriptor for the script

        2)  let the script be interpreted indirectly, through a frontend
            that makes sure everything is all right before starting the
            real interpreter - if you use the `indir' program from
            comp.sources.unix the setuid script will look like this:

                #!/bin/indir -u
                #?/bin/sh /etc/setuid_script

        3)  make a `binary wrapper': a real executable that is setuid and
            whose only task is to execute the interpreter with the name of
            the script as an argument

        4)  make a general `setuid script server' that tries to locate the
            requested `service' in a database of valid scripts and upon
            success will start the right interpreter with the right
            arguments.

      ---------

      Now that we have made sure the right file gets interpreted, are
      there any risks left?

      Certainly!  For shell scripts you must not forget to set the PATH
      variable to a safe path explicitly.  Can you figure out why?
      Also there is the IFS variable that might cause trouble if not
      set properly.  Other environment variables might turn out to
      compromise security as well, e.g. SHELL...  Furthermore you must
      make sure the commands in the script do not allow interactive
      shell escapes!  Then there is the umask which may have been set
      to something strange...

      Etcetera.  You should realise that a setuid script `inherits' all
      the bugs and security risks of the commands that it calls!

      All in all we get the impression setuid shell scripts are quite a
      risky business!  You may be better off writing a C program instead!