If an account has been assigned a normal UNIX shell (sh, csh, ksh), the account can create new shell scripts that can run any command in the system without privileges. Therefore, if none of its commands need privileges, a shell script can be used by anyone who has access to the script and its interpreting shell.
Making privileges available to commands that are invoked in shell scripts is done by the Security Administrator role.
Forced privilege commands are able to run with privilege in any shell because the forced privileges attached to the program file are available to the executing command. Assigning forced privileges to a csh, sh, or ksh shell script does not give any privileges to the commands executed by the shell script. Even though a shell that was started from the script runs with the forced privileges, the shell does not have any privileges in its inheritable set. See the rules for how processes get privileges, which are described in "Passing Privileges to Child Processes".
Shell scripts are vulnerable to being modified without detection. Before releasing shell scripts that use inheritable privileges, the security administrator should keep in mind that the protection against tampering that is available for programs is not available to shell scripts.
If none of its commands need privileges, a shell script can be created by anyone who is permitted to use a text editor.
A shell script can used by anyone who has access to the script and its interpreting shell.
Forced privilege shell scripts do not pass privileges to commands that they contain.
Allowed privileges on shell scripts have no effect on which privileges the programs executed by the shell script can use.
The allowed privilege set of the invoked shell's file is checked rather than that of the script's file.
Standard shell scripts do not use the rights profile mechanism.
A standard shell script that is invoked in a profile shell can pass privileges to commands that it runs if the Security Administrator role lists the shell script with any privileges required by its commands in one of the invoking account's profiles.
The shell script can pass any of its inheritable privileges to the commands it executes if the commands' executables have the allowed privileges. Because the commands are being run in a standard shell, it is no use to list them with privileges in one of the invoking account's profiles. The following figure shows a standard script executing in a profile shell.
Profile shell scripts, that is, scripts that begin with the line #!/bin/pfsh|ksh|sh, can pass privileges to their commands in whatever shell they are running. The commands must be listed with the required privileges in one of the invoking account's profiles.
Profile shell scripts behave differently when invoked by normal users than they do for administrative roles.
A shell script that invokes the profile shell can be executed by normal users on the command line in any shell.
If the user has All Commands in a profile, the name of the profile shell script does not need to be explicitly added to any of the user's profiles.
The commands in the profile shell script must be in one of the user's rights profiles, or the user needs the All Commands profile. Commands that need privilege must be assigned the required privileges in the profile.
A profile shell script ( using #!/bin/pfsh or any other profile shell) must always be run in a profile shell.
Roles cannot execute the profile shell from the command line or from a shell script (or bring up a GUI) without the trusted path.
A role must have the name of any script using a profile shell explicitly listed in the Custom role_name Profile or another rights profile for the trusted path to be available. (For ease in troubleshooting, we recommend using the Custom role_name Profile for all customizations to a role's rights.)
As is true for normal users, any commands in the profile shell script also need to be in one of the role's profiles.
To prevent unauthorized tampering with object code, any forced and allowed privileges previously given to a file are deleted whenever any executable program file is edited. This prevents someone from editing a file so that it uses privileges in a manner that was not originally intended. The Security Administrator role can save the list of privileges on such a file before editing it and restore them afterwards, as described in "To Save and Restore Privileges When Editing a File".