Firstly, a library developer does not know what world security their library is running under, so they don't know the features that are available without user intervention to authorise use. In the case of Linux, those feature sets are hard and typically fast-failing. Take for example shell(). To use shell() in a library, you automatically have to assume -trusted world security on Linux of the game that is using your library, regardless of their deployment scenario. You currently have no programmatic means for graceful fallback, notifying the game developer at run-time etc if this requirement is not met. Deployment requirements on a library aren't ideal for BYOND libraries, but in the general case I don't think it's entirely unreasonable for a library to have some requirement on the environment it runs under. However, the problem comes in the case of accidental mis-configuration. Even if the developer of a game knows the library they use needs -trusted access, and relays that in documentation to hosts, the host may not implement that. The end result is a support burden on the game developer, all because he chose library X. obviously he's not going to make that mistake more than once, making libraries using -trusted features disadvantaged. In the case where it's the only way to implement some functionality, it makes that functionality practicably untenable in general BYOND games. A library that breaks your game is not a good library.
The shell() scenario described above can be handled by a read-only variable like world.security, which means you can operate some form of notification or graceful fallback for strictly -trusted features (although programmatically closing off the option for host authentication in -safe on Windows). This solution however doesn't strictly lend itself to the second bird in my DLL specific case, what if the DLL just isn't there?
So what I propose is some functionality that allows the programmer to test if a specific operation would manage to run. My ideal solution may look something like this:
/security_manager
proc
file_call_permitted(var/operation, var/filename)
proc_call_permitted(var/operation)
dll_call_permitted(var/dllname)
world
var/security_manager/security
world
New()
..()
if (world.security.dll_call_permitted("my.dll"))
call("my.dll","initialise_socket","1092")
else
world.log << "\[ERROR\] Cannot initialise auxillary socket."
As far as the API goes, it de-couples me as a developer from BYOND's internals. You could freely add new security levels of even more granular security options to DreamDaemon, and the security manager would handle the complexities of that, saving me as a developer dealing with a system potentially in flux (particularly in betas of functionality). In the case of DLLs, I can stop caring where it is on BYOND's DLL call path (trusted folder, next to the DMB, elsewhere) and thus the security consequences of that AND if you're on Windows you can trigger a prompt to the host who can accept / reject before the proc call returns to me, like currently. I always get the accurate permissions, and can handle the case where I am not permitted to call it.
shell() and company are flat procs in the sense their security model is pretty much "You need -X security", hence the proc_call_permitted() test. File operations vary depending on the path of the file, hence what is usable in -safe for one file is not in another. Hence file_call_permitted().
The security implementation can be changed with the interface mitigating most of the risk, making you as platform developers free to tweak that without making my job as a library developer unduly difficult, and without needing to notify me in advance through notices or deprecation. Plus, as a separate object, there is potential for developers to extend the security manager at some later point if you want to go that way, to add their own permitted procs for libraries in a centralised implementation, and the object of course avoids polluating the world object namespace as it grows.
Aside from maybe the interface details (I can imagine cases where it needs generalising / expanding), any questions or problems with this approach?
This approach would save a lot of headaches.