Restrict Lua standard library #1317
Conversation
hash_random can be used to robustly make a selection based on some input data. For a lot of purposes, you want this and not a random number generator, because RNGs are hard to use nicely, and inherently tie together any an all code that touches them. I make no guarantees that hash_random will not change its output in future versions, but within a single version its output should be reliable across platforms, and because it's a hash you can explicitly and carefully control what inputs you wish to affect it.
this is still a crappy thing to do, and the functions still set global state instead of returning a value, but it removes the dependency on math.random/math.randomseed.
This is actually kinda dumb, because the custom systems use almost nothing from the Lua standard library, so this actually increases the amount of stuff avaiable in the context. But... consistency... :-/
|
I like the approach and the rationale.
For There is room for what might be termed abuses (libraries doing more than just defining the table, something else defining the table and thus stopping the thing loading), but its a very nice simple implementation. And it will continue to do the right thing if we start sandboxing modules in the future by giving each its own global table. In that case, |
|
I think If you look at the sysgen code, it uses an RNG seeded with the system path and universe seed, but because the samples taken from that RNG are interleaved with the complicated sysgen algorithm it's basically impossible to make controlled changes to sysgen: that is, if you change one bit of it you'll probably end up changing everything. That wouldn't be the case if hash based code were used. Instead of creating one RNG and then pulling numbers from it as needed, each number can come from a hash of (universe seed + system seed + key), where the key is, say, the name of the field you're generating. RNGs do become useful when you need a whole sequence of values and you want to be confident of the statistical properties of the sequence as a whole. For example, generating sampling points for stochastic sampling. You could do this as a load of separate hashes of (seed + counter), but that's slower and it's harder to be confident of the distribution because hashes have somewhat different design goals to RNGs. You may be right that (*) In fact, if you have a bunch of related seeds (e.g., system paths, where systems which are close together in space are close together in bit pattern), and you want to generate a random number for each one, and you want a uniform distribution of output values, then a real hash function is probably a much better choice than re-seeding an RNG for each input and pulling one number from it. |
That's actually a really good point. For NameGen I actually created a separate RNG to pass out to Lua just so it wouldn't screw things upl This would make things much easier. Case made - I'm sold! :) |
More importantly, the 'io' library is being disabled for safety reasons, so there's no way of emitting the core dump any more. pidebug can be brought back if/when someone adds a better debug output system and exposes it to Lua.
Pioneer has three different Lua contexts: the module system, LMR, and the custom systems loader. They each provide different things to their scripts, but until fairly recently they have exposed all of the Lua standard library, which includes various bits of functionality that makes scripts potentially dangerous or difficult to write correctly.
This PR defines a restricted form of the Lua standard library, and changes all three contexts to use that form. Each context still adds various extensions on top of this base.
Things this excludes from the Lua standard library:
osandiopackages: These are very dangerous since they let scripts read and write to any file on the system (if the user has permission), and execute arbitrary commands throughos.execute.math.randomandmath.randomseed: These behave differently on different platforms, and have uncertain statistical properties. Random number generators also tend to be difficult to use effectively if you have any requirements for isolation, repeatability, determinism and so on. These functions are the reason that the Lanner on the main menu looks different on different platforms.dofile,loadfile,requireand thepackagepackage: These bypass Pioneer's filesystem abstraction, so they don't work properly with installable mods or have platform specific behaviour. They also allow access to Lua scripts anywhere on the system (probably ok, but maybe not). Finally, thepackagepackage allows loading of native dynamic libraries, which is potentially dangerous.Things added to the Lua standard library:
math.deg2radis provided as an alias formath.rad, becausedeg2radis a better name.util.hash_randomis provided as an alternative to horrible hacks involvingmath.randomseedandmath.random. The module API provides real RNG support.hash_randomis just a useful way to make a deterministic choice from some arbitrary input data.TODO
require. Decision: Post-poned for a separate pull request, but most likely a function that works fairly similarly to Lua's standardrequirefunction (just hooked up to the file system to work properly with mods).requireisn't actually used right now, because all Lua scripts are loaded recursively anyway.util.hash_randomproperly, or move or remove it if it seems like a bad idea. Donepidebug.lua. It has been disabled for now because it uses theiolibrary, which is no longer available in that context. Decision: The core dump isn't actually useful in practice, so pidebug has just been completely scrapped for now, with the hope that someone will come in and implement better debugging tools in the future.