UNIX User Impersonation

A normal vovtasker has the privileges and limitations of the account in which it runs. When a normal vovtasker executes a command, the effect is the same as when the vovtasker's owner runs the command.

For Accelerator, jobs may be submitted by many users. To obtain the correct permissions with respect to files needed by the job, the vovtasker must be able to switch to the account of the submitter. On UNIX and Linux machines, this is done by having vovtasker run with root privilege. A simple method is creating a copy of vovtasker called vovtaskerroot, which is owned by root and has the setuid flag set. vovtaskerroot can be set up by running the script SETTASKERUID.csh.

To verify that vovtaskerroot is properly installed, go to the $VOVDIR/bin directory and check the access flags of vovtaskerroot. Verify the "s" character is in the fourth column (instead of the "x" character) as shown below: 
% cd $VOVDIR/bin
% ls -l vovtaskerroot
   -rwsr-sr-x   1 root    other     875092 Jan  5 11:57 vovtaskerroot
For security reasons:
  • The USER field for each job cannot be edited by any user, including ADMIN.
  • The vovtasker itself never executes any process as root. Instead, each job is executed as the user that first executed the job. If the user account does not exist on the tasker host, the job cannot be executed.

Other Methods of Starting vovtasker with Root Capability

Some sites may have security policies that prohibit setuid-root binaries, or prohibit setuid binaries from being mounted over NFS. Following are alternate methods to start vovtasker with root capability:
  • To start vovtasker from a boot file, use the available example .bat files as a guide to create a script, and place it in the appropriate directory. Example startup files are provided in $VOVDIR/etc/boot. Choose the one that best fits your scenario.
  • Use a setuid vovtaskerroot on a local disk.

Use a setuid vovtaskerroot Binary on a Local Disk

If the NFS filesystem (including the Altair Accelerator) is exported with the nosuid option, the vovtaskermgr command can still be used via a local setuid-root binary on each farm host.
Note: This method will add the cost of having to update the hosts individually when changing versions.

For example, the binary can be put at /opt/rtda/some-version/linux/bin/vovtaskerroot. It is helpful but not necessary if this path is the same on all farm hosts.

In this case, the setuid-root binaries must be created manually (the regular script is not useful. Following is an example of creating the setuid-root binary: 
% ssh some-farm-host% /bin/su -
# cd /opt; mkdir -p rtda/CURRENT/linux/bin
# cd /opt/rtda/CURRENT/linux/bin
# cp /network-path-to-rtda/CURRENT/linux/bin/vovtasker ./vovtaskerroot
# chown root: ./vovtaskerroot
# chmod u+s ./vovtaskerroot

After creating the local vovtaskerroot, set up the taskers configuration file of the Accelerator to use the local vovtaskerroot. The file is located in $VOVDIR/../../vnc/vnc.swd/taskers.tcl.

If the path to the local vovtaskerroot binary is the same on all farm hosts, change the defaults at the beginning of the file as shown below: 
if { [file executable /opt/rtda/CURRENT/linux/bin/vovtaskerroot] } {
    # Use vovtaskerroot from the local disk
    vtk_tasker_set_default  -executable /opt/rtda/CURRENT/linux/bin/vovtaskerroot
} else if { [file executable $env(VOVDIR)/bin/vovtaskerroot] } {
    vtk_tasker_set_default  -executable vovtaskerroot
} else {
    vtk_tasker_set_default  -executable vovtasker
}

If the path to the vovtaskerroot varies from host to host, add the -executable option to the definition for each host (instead of changing the default).