Bug #7169
openlua/output: vendored lua search for modules in /usr/local/ rather than /usr/
Description
I am trying Suricata 8.0.0-dev on current master and I am noticing that the new builtin Lua engine does not use the same search path as Suricata 7.0.6 for Lua modules.
If I install `lua5.4-sqlite` in Alpine Linux, then try to require lsqlite3 in a Lua output script, I get the following error:
Error: output-lua: couldn't run script 'setup' function: suricata-output-testscript.lua:17: module 'lsqlite3' not found: no field package.preload['lsqlite3'] no file '/usr/local/share/lua/5.4/lsqlite3.lua' no file '/usr/local/share/lua/5.4/lsqlite3/init.lua' no file '/usr/local/lib/lua/5.4/lsqlite3.lua' no file '/usr/local/lib/lua/5.4/lsqlite3/init.lua' no file './lsqlite3.lua' no file './lsqlite3/init.lua' no file '/usr/local/lib/lua/5.4/lsqlite3.so' no file '/usr/local/lib/lua/5.4/loadall.so' no file './lsqlite3.so' [LuaScriptSetup:output-lua.c:582]
This was working fine on Suricata 7.0.6: system-wide Lua modules were available to Suricata (e.e. `apk add suricata lua5.1-sqlite`).
Alpine Linux packages Lua modules in `/usr/lib/lua/5.x/lsqlite3.so`.
- https://redmine.openinfosecfoundation.org/issues/6961
- https://github.com/OISF/suricata/commit/bc011f220558947c061976af061939cb344cb864
Is this behavior intended? Shouldn't https://github.com/jasonish/suricata-lua-sys search for modules in `/usr/lib/lua/5.4/` rather than `/usr/local/lib/lua/5.4/`?
Updated by Jason Ish 11 days ago
- Related to Story #7128: lua: sandboxed lua support with mimimum set of bindings added
Updated by Alexandre IOOSS 9 days ago
Make sense! In that case shouldn't the Lua engine have an empty search path rather than /usr/local/share/lua/5.4/? Are you planning to block Lua `require` function?
I am using `sqlite3 = require("lsqlite3")` in a Suricata output plugin (in outputs.12.lua.scripts). Should I plan to rewrite it in C/Rust and load it as a Suricata plugin?
Updated by Jason Ish 9 days ago
Require will be blocked. We may alter the path to a Suricata managed location where specific modules exist that rule writers can depend on.
But I'm seeing you mentioned output, that will be more open to modules as output scripts aren't shipped/updated like rules are. Still need to be defined a bit I guess.
Updated by Jason Ish 9 days ago
I guess the main difference is that when using the system provided Lua, its path would be setup for the system. Using vendored, we don't know the defaults of the platform. We could build in assumptions, or make this configurable with an empty path by default, then let the user add to it as they enable output plugins.
Updated by Victor Julien 1 day ago
- Subject changed from lua: vendored lua search for modules in /usr/local/ rather than /usr/ to lua/output: vendored lua search for modules in /usr/local/ rather than /usr/