Allow running Simulate app with plugin libraries from any folder

[scastro-nasa]

The feature, motivation and pitch

Hi all -- I'm an engineer working with NASA on building out tools/applications with mujoco_ros2_control.

One thing that we have been working on is making new plugins, which works great with our custom entrypoint in mujoco_ros2_control.

However, we run into limitations running the simulate app standalone with our custom plugins if MuJoCo happens to be installed in a root-owned folder. This is due to the logic below, which assumes plugins are placed in a specific location which is tunable via preprocessor directive, but always is relative to the mujoco executable directory -- meaning that users have to copy their plugin libraries to this folder when they may not necessarily have permissions to do so:

mujoco/simulate/main.cc

Lines 189 to 197 in 080668d

	const std::string plugin_dir = getExecutableDir() + sep + MUJOCO_PLUGIN_DIR;
	mj_loadAllPluginLibraries(
	plugin_dir.c_str(), +[](const char* filename, int first, int count) {
	std::printf("Plugins registered by library '%s':\n", filename);
	for (int i = first; i < first + count; ++i) {
	std::printf(" %s\n", mjp_getPluginAtSlot(i)->name);
	}
	});
	}

Would the maintainers be amenable to providing some kind of environment variable, command-line args, or other mechanism where users could specify additional paths to scan for plugins that may be anywhere on a user's file system? Or maybe we're unaware of an existing mechanism to do this.

We're happy to contribute changes, but wanted to get alignment from maintainers. Thanks for your help!

Alternatives

Our only alternative, really, is what we have working now: Automation that tries to copy the built plugin libraries to the install location, but gives users a warning if there is a permissions-related failure or their simulate binary is not found, prompting them to manually do the copying if possible.

Additional context

No response

[saran-t]

The reason that it's done this way was because I'm a bit uneasy about shopping a binary that's capable of silently running arbitrary code (it doesn't even need execute permission to do this) that's dumped in the user's local directory.

I have no objection in principle to you introducing a CMake option that injects additional lookup paths for custom builds. Free free to send a PR.

Do you strongly prefer environment variables to a compile time change?

[scastro-nasa]

Thank you! I think we were looking for something that allowed directly using pre-installed mujoco binaries in addition to building from source, which is why I mentioned environment variables / CLI args. So unfortunately, we can't rely on a compile-time change in all our envisioned use cases.

But if there is a significant security concern that eliminates that option, it's good for us to know so we can explore alternatives.

[saran-t]

Happy to brainstorm on this.

The issue that concerns me is that it'll open an attack vector where an environment variable injection can allow simulate to execute arbitrary ELF binaries that the user has read access to. Now arguably any interpreter is already capable of doing this (python will happily call dlopen if you tell it to) but in my mind there's an expectation of arbitrary code execution in an interpreter. For something like simulate I'd argue that's very much unexpected.

Here's a possible workaround in your use case (admin preinstalling simulate in a system directory, I'm assuming): you can author your own "plugin" DSO that scans whatever directory you want in the user's home directory and loads plugins that it finds.