> (Perhaps the path change should be in its own ticket, leaving
> this one for the wider discussion.)

I had to update the patch again, so I did create a new ticket: bug #19911.

Untested patch to have database.lua in $sysconfdir/freeciv/. Untested since my primary development machine is down and I don't have mysql setup on this one. Can someone test?

Note that since $sysconfdir/freeciv is the only location database.lua is looked from, it cannot be used directly from builddir.

(file #15976)

data/database.lua (the Lua script handling authentication and database access in 2.4+) is loaded in its own Lua instance, separate from the instance in which the older server-side "game"/"scenario" scripts run.

However, the "auth" Lua instance gets the same restricted environment that "scenario" scripts do (see bug #15624, bug #15725).

Right now this is a pain for me because for patch #3287, I want to call Lua's os.time() rather than invoke non-portable SQL time functions (as used currently). The "os" module is not included in the restricted environment.

In general, it seems a bit daft for the database script, which has read/write access to some of the highest-value data the server deals with (user credentials) as well as a suite of general-purpose database access functions, to run with the same restrictions as "scenario" scripts. Perhaps this instance should run in an unrestricted Lua?

The threat model which the Lua security measures are responding to is a bit murky. Bug #15624 indicates that the desire is to allow users to continue to confidently treat downloaded scenarios/rulesets as "simple data", without any risk that embedded scripts can have any nasty effects beyond the game environment they're running in (such as disclosing or overwriting user data outside Freeciv). Now we have freeciv-modpack, that assurance should probably extend to anything a user downloads with it.

It seems fairly clear that that threat model shouldn't apply to database.lua, because that's essentially part of the server. So it's tempting to remove the restrictions for the auth instance. (Perhaps that would also mollify Michal per bug #19006?)

However...

database.lua is loaded from the data path, which defaults to:

and can be overridden by environment variables FREECIV_DATA_PATH and FREECIV_PATH. Thus, there is plenty of scope for an attacker to override the standard database.lua by tricking a user into running the server from a chosen directory, or (I think) by tricking them into downloading a dodgy modpack via freeciv-modpack.

Even with things as they stand, such an attacker would be able to impersonate other Freeciv server users, or possibly leak their credentials via side channels. If we remove the Lua restrictions for database.lua, they could do much more.

Looking at the contents of data/, I think database.lua is probably the first file in there with this sort of security property. Other "code"-y files include game scripts (handled by existing Lua security) and .serv files (only limited potential for mischief -- "save ~/.bashrc").

So, even if I find another solution for my os.time() issue (such as whitelisting bits of os.*), we still have a problem. What should we do about it?

• Invent a new category of "data" file, with database.lua as the only current member, loaded from a much more restrictive default path that only includes the installation path (cf patch #2827)?
  • How will a non-root server operator override it on a machine where Freeciv is installed system-wide? Is an environment variable acceptable? That would still be sufficient guard against the dodgy-modpack / chosen-directory attack.

If we do mitigate the path problem, would there be any other issue with relaxing the restrictions on database.lua?