2.2.5. Enable Test Jobs (Optional)
The disadvantage to this scheme is that, since the user's mapper and reducer are run directly by the WMRServer daemon, they inherit its privileges and can potentially view confidential information such as passwords and SSL keys. For this reason, test jobs are disabled by default.
WMRServer provides a way to secure test jobs by setting a command that the daemon can use to run test jobs under a different, unprivileged user. On most Unix-like systems, the easiest way to achieve this is through the sudo
package. Instructions relating to sudo are provided; you will have to adapt these instructions for other systems.
2.2.5.1. Sudo Configuration
With the sudo package installed, open the sudo configuration for editing using the visudo
command:
$ export EDITOR="nano"
# or your favorite command-line text editor
$ visudo
We want to allow WMRServer to execute arbitrary commands under a specific account without providing a password. To do this, add the following line to the configuration:
wmrserver-user
ALL=(test-job-user
) NOPASSWD: ALL
Here, wmrserver-user
is the name of the WMRServer account, and test-job-user
is the other unprivileged user. On most systems, the nobody
account is the best choice for the latter.
Important
Be aware that this allows any process or user running under the wmrserver-user
account to run any command under the test-job-user
account. As long as test-job-user
is an account without any special privileges, like the nobody
account that exists on many systems, this should not cause any serious security issues.
You may also need to add the following setting, which allows non-interactive sessions to use sudo, to the configuration:
Defaults !requiretty
Finally, quit visudo (by exiting the text editor) and run the following command under the WMRServer account to test your configuration:
$ sudo -nu test-job-user
whoami
If successful, the command should simply output the name of the test job account without prompting for a password.