Page History

...

• the worker process is usually started at system boot time and runs as long as the system is up
• the worker process runs as either a Windows service or a daemon owned by the root user on OS X and linux.
• the worker process will run jobs under another a user other than root or the system service; which user it will run the jobs as . This user is determined by the proxy_execution_mode value;:
  
  • proxy_execution_mode = proxy means it will always authenticate as the user defined in proxy_account.
  • proxy_execution_mode = user means it will always authenticate as the user who submitted the job.

...

When the Worker launches a remote job as dispatched by the Supervisor, it can potentially create several processes, all controlled by the Worker. Since Qube is designed to emulate a user executing jobs on a remote host, the Worker will have to run these processes as a some user.

Under Unix-based operating systems, all that is required is the setting of a "setuid" bit that enables a privileged process to then run as any userthe Worker does a setuid in order to switch user identities before starting the process. 

On Windows, this is handled quite differently. Under Windows, any process attempting to impersonate another user will have to produce certain security information, including the user's encrypted password. So the Worker can produce this information every time it creates a new process, the information is stored in the Supervisor and handed to the Worker when requested by the System. The Worker creates an authentication token when it creates a new process, and the System then permits the process access to the user's environment and files.  For this reason, if running with proxy_execution_mode = user on Windows, every Windows user will need to register (and keep current) their password with Qube.  Most facilities choose proxy_execution_mode = proxy when running in service mode on Windows.