Taskers Running as Root: Security Implications

A normal vovtasker, as described in Taskers, 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.cshs.

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:

Start vovtasker from an init.d script.
Use a setuid vovtaskerroot on a local disk.

Using 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 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).

Server Impersonation on Windows

In Windows, there is no superuser identity such as root that can switch to other accounts without providing any credentials. For Accelerator on Windows, a different method is used to run jobs as the submitter.

In Windows, the vovtasker calls a Windows API to create a process with a username and password. The username is mapped from the UNIX/Linux username, and the password is stored in encrypted form in the vovserver and passed to the vovtasker. The password is destroyed immediately after use. It is possible for a UNIX/Linux user to run jobs as another Windows user, by logging onto the machine locally with the account name and password.

After the Windows process is running as the correct user, it may need to mount any filesystems needed, as each user has their own set of drive letters in recent Windows versions. For details, refer to Vov Windows Impersonation.