I am a bit confused, and from reading some conversations, it looks like I am not the only one, by the assumptions over CSMs. I feel like the definition and the security model of CSM shifted in the last two years.
Nowadays, it is mostly about running scripts sent by the server, so CSMs (or SSCSM as I sometime see server-provided CSMs called) are aggressively sandboxed, because you never know when you are going to connect to an hostile server, and you don't want to offer remote execution vulnerabilities.
It looks like, however, that before SSCSM were discussed, CSMs were mostly user-provided, and as such understood to contain the same security risk for the user than installing a server mod has, for a server administrator. One could see a local CSM as an alternative to forking the client and painstakingly adding modifications in C++.
I kind of miss this second model. I am currently exploring the possibility of interfacing a good text editor with minetest (probably through an atom plugin) but the current CSM security model makes it extremely difficult for (I feel) no good reason.
I'd like the ability to add local mods to `secure.trusted_mods`. I understand that you probably don't want to give that option to server-provided mods, but user-provided ones should have it.
Currently I have identified two ways to communicate with another process, both pretty hacky:
- The minetest-mumble-wrapper captures minetest's process stderr and reads outputs by a CSM to get the player position. It is uni-directional and uselessly fills logs.
- I can read the `client/mod_storage` file and hack some bi-directional communication there. Unfortunately there is no locking mechanism (it is a json file, not a .sqlite file) and quick reactions would require parsing the whole file (that could quickly grow in size) several times a second. Things can get messy quickly with two process trying to write to the same file.