Plugin Sandboxing¶
Overview¶
Plugin Sandboxing is a feature that was introduced in Deadline 8.0 that allows plugins and event plugins to run in a separate environment. This gives each new instance of a plugin free reign to modify its environment without adversely affecting any future instances of the same plugin, other plugins, or the Worker itself.
How Plugin Sandboxing Works¶
Plugin Sandboxing works via an executable that sits alongside other Deadline Client executables called the Sandbox. If run on its own, it will do nothing but exit immediately. The Sandbox can only be initialized by the Client applications, who are able to communicate with it and use it as a sub-process to run Python plugins.
More specifically, the Worker will create one Sandbox for each render thread every time it dequeues a new Job. Each Sandbox executes one instance of the render plugin and will terminate when the plugin finishes, essentially allowing each plugin to run in its own independent environment. The Worker captures all of the output generated by the Sandbox to generate logs and reports.
Similarly, event plugins are also relegated to the Sandbox. However, to keep the number of processes down, each application creates a single dedicated Sandbox to run event plugins. If an event causes the Sandbox to hang or crash, the current Sandbox process will be terminated and a new one is started to take its place.
Advantages of Plugin Sandboxing¶
From a computing perspective, it is generally beneficial to separate independent tasks from each other. By making the Sandbox its own process, we take advantage of the separation that the operating system itself provides between processes. This improves stability by making it much harder for a plugin (or its associated application) to affect other plugins or the operation of the Worker itself.
In addition, Plugin Sandboxing also provides consistency. Since each plugin is run in a fresh Python process, it will not be affected by environment changes made previously, possibly by an entirely different plugin (nor will its own environment changes affect future plugins). This will also avoid any potential issues caused by Python’s module caching, as changes made to dependent modules should now be reflected much more transparently when imported.
Rendering as User¶
We used Plugin Sandboxing to improve the Render Job As User feature in Deadline 9.0. This feature allows Jobs to be rendered as the user that submitted them. Previously, this was limited to the application associated with a plugin. While the application was guaranteed to be run by the render user, the plugin script itself would still be run by the same user that launched the Worker.
Starting in Deadline 9.0, rendering a job as a user now applies to the plugin script as well. The Sandbox sub-process for that plugin is now launched as the render user, ensuring that the Python script runs in that user’s environment. This is beneficial if your user’s environment defines variables that need to be set correctly for the plugin to run as expected, or if the plugin needs to read/write files that have user access permissions. Pre/post Job Scripts are also run in this context.
Note that event plugin scripts are not run as the render user, due to the fact that Client applications each use a single dedicated Sandbox process for event plugins. Since there is only one event Sandbox per application, it is run under the same user that launched that application.
