Feedback on Lua Sandboxing Restrictions: Request for a Power-User Toggle Flag

[Vactarian]

First of all, thank you to the team for the incredible, tireless work you put into maintaining DFHack. It is an indispensable framework that completely transforms how many of us experience Dwarf Fortress.

I wanted to provide some constructive feedback regarding the safety overhauls implemented in the DFHack 50.11 release cycle (specifically November/December 2023), which introduced strict sandboxing to the Lua environment by removing native OS functions like os.execute and io.popen, alongside subsequent blocks on launching local execution shortcuts (.lnk and .exe files) from configuration paths.

While the intent to protect the broader user base from malicious mod packages is entirely understandable, enforcing an unyielding, mandatory sandbox significantly degrades the experience for power users while introducing a fundamental paradox: DFHack operates natively as an extension library directly integrated into the game's executable stack with full system privileges, yet it draws an arbitrary line at preventing users from utilizing those exact same custom automation capabilities within their own workspace.

Malicious actors intent on exploitation will always bypass high-level script restrictions through memory manipulation or alternative execution pathways. Consequently, a mandatory sandbox does not truly secure the ecosystem; it simply acts as security theater that penalizes legitimate power users who have already established a baseline of trust with the scripts they choose to install.

The most glaring impact of this model occurs when attempting to synchronize essential sidecar utilities like soundsense-rs with the game. To ensure that the Steam client can natively track playtime hours, manage cloud saves, and maintain the Steam overlay, the game must be launched directly through Steam.

In an open environment, automating a companion tool alongside the game should be a trivial task—achieved via a single, clean command line in a startup script or by placing a minimized shortcut in an initialization folder.

Instead, because the framework aggressively blocks these native inter-process communication pathways, power users are forced to waste time constructing fragile, multi-layered external architectures. We are forced to chain hidden VBScripts and background batch scripts just to intercept Steam's launch parameters, handle background execution, and forcefully pull windows back into active focus.

To resolve this structural barrier without compromising the safety of casual users, I respectfully request the implementation of a simple, opt-in initialization switch or command-line flag (e.g., an environment variable, a startup argument like --allow-external-scripts, or a GUI checkbox toggle with a clear warning prompt).

This would allow advanced users to knowingly disable the sandbox safety net at their own risk, restoring full API and system execution capabilities to those who heavily value custom automation and seamless workflow integration.

Thank you for considering this QOL adjustment for the power user community.

[Correction: DFHack isn't an external injector anymore; it runs as a native extension library.]

[Vactarian]

To ground this request in a practical scenario, the exact issue that triggered this feature request was an attempt to get soundsense-rs to automatically launch alongside the Steam version of Dwarf Fortress. Because I want Steam to track my playtime hours, manage cloud saves, and handle the overlay, launching the game natively through the Steam client is mandatory.
Ideally, initializing a sidecar companion tool should be trivial, achieved via a single line in a startup script or by dropping a standard Windows shortcut (.lnk) into an execution folder or a simple lua script dropped in the scripts folder.

Because of the hardcoded sandbox, this is impossible. To achieve a basic automated launch, power users are forced to engineer a bloated, multi-layered workaround outside of DFHach, having to chain VBScripts and background batch files just to intercept Steam's launch parameters, handle silent background execution, and use PowerShell focus-hooks to forcefully grab the game window and drag it over the desktop view.

Beyond user-side frustration, this mandatory sandboxing creates massive structural bottlenecks for mod developers and alters user safety psychology in counter-productive ways:

• Severe Modding Bottlenecks: When a modding framework completely bars native inter-process communication (IPC), it stifles innovation. Modders cannot easily connect Dwarf Fortress data to external web dashboards, live streaming overlays, Discord rich presence tools, external hardware integrations, or advanced text-to-speech engines. It forces modders to write redundant code, split their utilities into fragmented external binaries that users must manually launch, and waste countless development cycles troubleshooting brittle external wrappers rather than refining actual mod functionality.

• The "False Sense of Security" Trap: Ironically, forced sandboxing actively degrades user safety awareness by altering user psychology. When a platform advertises a mandatory, completely locked-down environment, users become complacent. They stop reviewing the scripts, blueprints, or configurations they download because they mistakenly believe the framework completely sanitizes the environment for them.

• Legitimate vs. Malicious Adaptability: A malicious actor determined to execute an exploit will bypass script-level sandboxes by leveraging memory vulnerabilities or raw injection pathways that a high-level block cannot stop. Legitimate modders and power users, however, strictly adhere to standard execution practices. Consequently, a mandatory security barrier does nothing to deter a sophisticated attacker, but completely strips the toolbox away from legitimate creators.

Some might say that Dwarf Fortress now features native Lua modding capabilities, and that system-level actions should be left out of DFHack entirely. However, looking closely at the native vanilla Dwarf Fortress modding framework, the native game engine is even more aggressively isolated.
Native DF Lua scripting is strictly intended for procedural object generation (e.g., custom raws, curses, forgotten beasts, and magical interactions). It has absolutely zero exposure to the operating system's environment, meaning it is completely impossible to handle external process management, audio triggers, or sidecar utility execution natively.

Because native Dwarf Fortress does not provide these capabilities, the community heavily relies on Dfhack to be the bridge that makes advanced tooling possible.
Security should always be an onion of defense, not a locked room that traps your power users inside. By implementing a simple, explicit startup flag or environment switch to toggle this sandbox off, DFHack can maintain its blanket protection for casual users while liberating modders and power users to build seamless, integrated automation workflows.

When a modding framework completely removes core API functionality like os.execute without providing any configuration override, it stops acting as a layer of defense and begins acting as a physical chain.
Security models should adhere to a fundamental ethical boundary:
software must never lock a user out of control over their own physical hardware.

If a user explicitly decides they want to run a sidecar tool alongside their game, a security safety net should not make it harder for the exact person it is designed to protect.

When a security policy forces a power user to build convoluted, multi-script hacks outside the platform just to open a basic audio tool, the security framework has failed its user base. It is no longer protecting the user from an external threat it has become the primary threat to the user’s workflow, productivity, and overall experience.

True security empowers users with transparent choices and clear warning labels; it does not treat legitimate owners like hostile adversaries on their own machines.

[ab9rf]

Simply put, this is a hard no.

This above exposition is riddled with errors, both factually and conceptually. For example, we disabled io.open in 50.05-alpha, which was actually before any of the post-v50 releases, not in 50.11 as alleged above. We also have no logic that explicitly disables .exe or .lnk files from being opened during initialization - we simply have no logic, nor have we ever had any logic nor would be ever contemplate adding such logic, which attempts to launch such files. DFHack will open them just fine, but it'll try to parse them as script files which is simply unlikely to yield meaningful results. Furthermore, DFHack has (and has long had) established mechanics for RPC which is already being used by other developers in the ecosystem to implement several of the things that the proponent claims are made impossible by our lack of RPC mechanics.

A security model that has a readily-available "off" switch is not secure. If we had a configuration option to turn off security, all malicious code would have to do is inject that setting into an initialization file.

The DFHack team does not consider os.execute or io.popen "core technologies" to the Lua environment. We disabled them because we judged that the risk to consumers exceeded the benefit to modders. Nothing in the above exposition changes my mind on this issue - if anything, it reinforces for me that we made the right choice here originally, and that we should not disturb it for this request.

The problem I have with this request is that it is grounded in so much misinformation and such grave misunderstandings of the problem space that I don't trust that the proposer understands what they're asking for or even that the proposer does not have ulterior motives. As such, this request will not be implemented.