In 99% of the cases, this behaviour is identical to before.
With this commit, it is again possible to have 'builtin' a symlink that e.g.
points to the engine source directory, which is helpful for development purposes.
It's likely that these could be used trick mods into revealing the insecure
environment even if they do everything right (which is already hard enough).
- Move the text segment below the 47-bit limit, needed for script_exception_wrapper which must be lightuserdata
- Replace CUSTOM_RIDX_SCRIPTAPI with full userdata
Safety-guards for CSM callbacks to abort on a bad implementation
Only run callbacks when the mods are loaded (and with it: builtin)
Duplication checks inside constructors
* Modernize lua read (part 2 & 3): C++ templating assurance
Implement the boolean reader
Implement the string reader
Also remove unused & unimplemented script_error_handler
Add a reader with default value
* Modernize source code: last par
* Use empty when needed
* Use emplace_back instead of push_back when needed
* For range-based loops
* Initializers fixes
* constructors, destructors default
* c++ C stl includes
* Load client-side mods into memory before executing them.
This removes the remaining filesystem access that client-sided mods had and it will hopefully make then more secure.
* Lua Virtual filesystem: don't load the files into memory just scan the filenames into memory.
* Fix the issues with backtrace
* fix most of the issues
* fix code style.
* add a comment
* Resource leak: CHECK_FILE_ERR returns, without freeing chunk_name.
Found with static analysis.
* Resource leak: leaks `page` on error path.
Found with static analysis.
* rename GameScripting to ServerScripting
* Make getBuiltinLuaPath static serverside
* Add on_shutdown callback
* Add on_receiving_chat_message & on_sending_chat_message callbacks
* ScriptApiBase: use IGameDef instead of Server
This permits to share common attribute between client & server
* Enable mod security in client side modding without conditions
Trying to resolve a path with RemoveRelativePathComponents that can't
be resolved without leaving leading parent components (e.g. "../worlds/foo"
or "bar/../../worlds/foo") will fail. To work around this, we leave
the relative components and simply remove the trailing components one
at a time, and bail out when we find a parent component. This will
still fail for paths like "worlds/foo/noexist/../auth.txt" (the path
before the last parent component must not exist), but this is fine
since you won't be able to open a file with a path like that anyways
(the O.S. will determine that the path doesn't exist.
Try `cat /a/../etc/passwd`).
