Project

General

Profile

Actions
Copy link

Bug #7169

open

lua/output: vendored lua search for modules in /usr/local/ rather than /usr/

Added by Alexandre IOOSS 4 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
OISF Dev
Target version:
TBD
Affected Versions:
git master
Effort:
Difficulty:
Label:

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`.

Related issue and commit:

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/`?

Related issues 1 (1 open — 0 closed)

Related to Suricata - Story #7128: lua: sandboxed lua support with mimimum set of bindingsNewVictor JulienActions
Actions
Copy link
 #1

Updated by Jason Ish 2 months ago

For 8.0 we are hardening Lua and have removed the ability to load external plugins. See #7128 .

Actions
Copy link
 #2

Updated by Jason Ish 2 months ago

  • Related to Story #7128: lua: sandboxed lua support with mimimum set of bindings added
Actions
Copy link
 #3

Updated by Alexandre IOOSS 2 months 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?

Actions
Copy link
 #4

Updated by Jason Ish 2 months 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.

Actions
Copy link
 #5

Updated by Jason Ish 2 months 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.

Actions
Copy link
 #6

Updated by Victor Julien about 2 months 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/
Actions
Copy link

Also available in: Atom PDF