|
|
With the introduction of support for multiple file formats in SCO OpenServer, it is possible to have set-id and privileged shell scripts. In addition, there have always been shell scripts that are used by administrators. If a shell script can get administrative access to the system it must be trusted, so rules for trusting shell scripts are needed as well.
The primary rule of trusted shell scripts is: any shell script that uses privilege or special access rights is subject to spoofing and must not be available to non-administrators.
The documentation needed for a trusted shell script is the same as that for any other trusted command (see ``User documentation'').
The shell offers no way to control special access rights granted by the set-id feature and only limited ability to regulate privilege. Without this control, such a shell script must be extremely simple before it can be trusted. In general, it is not a good idea to use the set-id mechanisms for shell scripts. Only trusted commands should be used in shell scripts.
The shell's limited ability to regulate privileges is provided through the new built-in priv command. This command can be used to manipulate both working and fixed privileges of the shell. Note, though, that removing privileges from the shell's working privilege set is ineffectual in preventing these privileges from being propagated to executed commands, since it is the maximum privilege set that determines what privileges an executed command will have. But removing privileges from the maximum privilege set is permanent -- they cannot be regained later for propagation to a command that needs privileges. As such, writing a trusted shell script that propagates its privileges only to the commands that need it can be rather unwieldy. In general, it is best not to give the privileges to the shell script itself. Instead, leave the shell script unprivileged, and whenever the script needs to invoke a command with privilege, it can invoke that command through tfadmin. In this case, all commands invoked through tfadmin must exist in the TFM database, and all users who are to execute the script must have access to them.
If a script must be run with privileges, that first line of the script must be "#!/sbin/sh -p".
Most commands report the errors they encounter and exit with a non-zero return code on failure. Shell scripts, therefore, usually do not need to bother reporting errors. Nonetheless, shell scripts should check for errors. A command that fails and reports an error indicates a problem in the shell script. If that error might cause the system to be left in an inconsistent state by the script, the error must be caught and handled. Whether the error is specially reported depends on the particular circumstances.
For example, if the failing command redirects its standard error output to a file or to /dev/null, the shell script must report an error to avoid failing silently.
If, on the other hand, the command does nothing to redirect messages, then the command's error message should be enough to tell the user what happened.