Author
Topic: new driver development. (Read 6334 times)

Given that FallenTree is reluctant to add support for the old mudlibs with the 3.0 release I was wondering if anyone might be interested in working on a new driver. This is kind of a project I have been thinking about on and off for sometime. My current idea is to write it in either Java or Node.js. My main reason for selecting Node.js is because I would like to learn the language (or typescript) but Java has a concurrency model that could potentially support more features in future (such as the STM like stuff they have in Hydra). The idea is to be fully compatible with the FluffOS 2.xx line.

I have some reasonably detailed plans that I have outline over the years and now have perhaps a few months to work on it. I suspect given that I can combine and clone the actual grammar with the ANTLR grammar in the code vault it might be possible to get lillib to compile and run. If anyone is interested in helping out a little bit let me know. I think it would be fun.

I think is also room for new ideas in how a programmable system like an lpmud driver should run nowadays. I have recently become interested in probably somewhat old stuff to most people- cloud computing via AWS and NoSQL style databases like Cassandra. So I have been wondering if a mud could be backed by some of these kinds of systems and be distributed over multiple machines for robustness.

A new driver would be great but remember mud admins are lazy easily spooked creatures of habit. basically, unless you spoon feed them... "Make it really really easy" for them to change they simply won't because they consider the driver they are running on stable.

From memory, most muds changed to fluffos around the time cratylus changed deadsouls to use it and discworld was using it in prime time for quite some time, so from that most thought, it was trust worthy and stable.

So I see this being an issue unless you can get a large mud to use it and stand by it not many will make the change. hence why fluffosv3 is a big waste of time. as its too much effort to make the transition, No English Muds are using it and it's bloatware which is a big turn off for older mud admins.

Personally, I think time would be better spent maintaining the version 2 branch of fluffos with patches as things change but that's just me if I had the time I would do it

I think that FallenTree's stuff has a lot going for it and probably it is being used in situations where there is more active development (chinese muds). I think perhaps the english speaking community has grown too small for him to feel that it's worth the effort to support even though it isn't that much work really IMHO. It just requires setting up some integration testing system where one at least can boot the existing mudlibs with various different compile options.

I talked to him via email and it seems he is not willing to do it so I am not sure if I will help out in his efforts to further improve the system.

Writing a driver is a much easier task than it use to be given that we now have many vm based languages supporting features such as dynamic loading. One can basically write a LPC->lang of choice transform with instrumentation for dynamic checks need for security etc. and have all the code run directly on the vm without having to write your own.

It would be nice to have some help once I have the basics taken care of (language transformer and lightweight runtime). Since there are certain portions of the conversion process which requires a lot of grunt work and might take sometime unless there are a sets of hands doing it at the same time such as reimplementing the various efun packages and perhaps the language parser for dead-souls which i don't really understand that well.

TBH, I didn't say I won't add support for older libs in FluffOS3, In fact, all compatibility issues that ever been raised on GITHUB already has a solution, I'm not sure what the exact issue is.

All in all the driver is generally going towards an configuration based instead of compile options based system, which make it possible for people to pair an generic driver with some runtime config and run all the old mud. If there are some specific active MUDs that want to try to transit to FluffOS 3 , I'm willing to work with you and support them.

Please submit your question with specifics on the github, instead of just say, stuff doesn't work.

This is kind of off topic but I suspect the problem is many of these libs aren't on running muds as of today but still represent a significant body of work and people interested or playing with english language muds and mudlibs might still have some interest in them- so some system perhaps is needed to perhaps at least boot up and test some of these muds and make sure they still work when driver modifications are made.

There are some changes besides the removal of the discworld extensions that make me a bit uncomfortable since I am unsure of what was accomplished. One of these is the change to the sort algorithm which I haven't really looked at. The old one is a bit odd because it is designed not to behave badly even if someone passes in a strange function to determine the sequence order. Is this still the case with the new function?

The other two i noticed i posted on the github already. I probably (back on topic) will be working on a new driver over the next month to see how difficult it is with modern tools.

I posted a slightly buggy version of a stripped fluffos grammar with just the context free grammar portion of the rules. I say buggy since i by mistake deleted some portions of the alternations when stripping the file by hand. I will try to test and post an updated grammar for fluffos in antlr4 soon.

I am still on-track to release a Node.js "driver" / mudlib by the end of the year. The mudlib itself is lagging behind a bit as I have spent much of my time tweaking the driver (still have to write combat logic, etc). I would not recommend spending too much time on it yet (although git makes it really easy to keep in sync with dev).

* MudOS compatibility mode. This will import virtually every efun name from MudOS/FluffOS into an object's context when loading (e.g. load_object, etc). There is a master() object and simul efuns. Objects can be re-loaded during runtime and have immediate effect.

* Extensible compiler pipeline. Easy to add support for new transpilers (e.g. typescript and possibly LPC).

* Focus on web-based clients but with support for legacy/telnet clients (including GMCP... although I have never used this telnet extension).

* Included web client provides Monaco editor, visual file explorer, etc (still lots of work left to do here).

I noticed there is some code in your repo for two transpilers. I do have a question and perhaps a suggestion of sorts but I am not sure I know javascript well enough to understand exactly what I am reading.

1). Is there a distinct mud library/driver code distinction in the code or is it more like a diku? If so, does the transpiler for the mudlib portion support security instrumentation?

2) If the CPU is a resource does the instrumentation check for too long executions in case of infinite loops and too deep recursions? Or is there some other means of handling this with node.js?

3) There seems to be some preliminary LPC support added perhaps a week ago or so as well. I was thinking about doing something similar but I was a bit uncertain about how to best do this in ecmascript 6. I suspect writing this is some work.

I noticed there is some code in your repo for two transpilers. I do have a question and perhaps a suggestion of sorts but I am not sure I know javascript well enough to understand exactly what I am reading.

1). Is there a distinct mud library/driver code distinction in the code or is it more like a diku? If so, does the transpiler for the mudlib portion support security instrumentation?

There is a distinction between the mudlib code and the driver. The driver is loaded in Node's native context and mudlib objects are compiled and instantiated in a vm sandbox context. The driver has access to system resources but mudlib objects should only have access to the resources the driver provides to the sandbox (efuns, etc). I am curious to see if some brilliant hacker can break out of the sandbox. Hopefully the Node developers made it fairly fool-proof.

Is there some specific security concern you think I should worry about? The current security model is heavily influenced by MudOS/FluffOS. Regardless of which pipeline is used to create an object the resulting code can only access the mud resources through the efuns object. Reads, writes, shutdown requests, exec, etc, all perform stack-based checks against the driver + in-game master object applies. Oh, I should mention that important security tokens like filename, instanceId, etc, are baked and sealed into the object when they created and in theory cannot be changed.

2) If the CPU is a resource does the instrumentation check for too long executions in case of infinite loops and too deep recursions? Or is there some other means of handling this with node.js?

I currently have a max execution time on object creation but I need to add one for initial compiling as well. I also need to add support for max command execution time and throttling to limit commands/second for any given object. I am using a module called Tripwire to try and prevent malicious code like while(true);

3) There seems to be some preliminary LPC support added perhaps a week ago or so as well. I was thinking about doing something similar but I was a bit uncertain about how to best do this in ecmascript 6. I suspect writing this is some work.

The LPC to JS transpiler is on my to-do list but not a high priority for me. I lost my original MUD to bad DVD media (10,000+ hours down the drain). The LPC support is currently limited to the module I created to handle MUD socket communication for Intermud support (although I suppose it could be used to read object files, too). The only real compat buster so far relates to how virtual objects are created. MudOS returns an object instance and applies filename, etc, to the resullt. In this driver the master can only tell the driver HOW to create the object (the master provides a filename to instantiate and initialization data and the driver then creates the object).

Also worth noting: Object instances do not hold their data directly. Each object instance has a storage object contained within the driver that they access. The driver also uses the storage object to send important signals to the object instance via events (body switches via exec(), user input from the client, etc, are passed this way). The storage object is only in scope within the constructor chain and again during create() so the object can wire up events.

Does all the code in the mudlib reside in a single sandbox? I am wondering if there are security measures to prevent coders from tripping on each others toes. I am not familiar with the tripwire module you mentioned do you have a link? I am curious if it prevent's all malicious code where the code takes too many cpu cycles to execute and how it does so.

Each distinct type is created in its own sandbox. The sandbox has an efun "proxy" which is imprinted with the filename and permissions inherent to that file. The proxy performs security checks and passes valid requests through to the underlying external function object that does the sensitive stuff like reading files, writing files, accessing the network, etc. Once the object is created in the sandbox then it is made available to the game. Objects can import references to existing objects, though (permissions permitting). This allows for inheritance, etc.

I have found and fixed one security issue already, though. You could replace applies in the master object at runtime by altering the master's prototype (e.g. master().constructor.prototype.validRead = function() { return true; }).

The master objects and efun objects are frozen just before the game enters the running state now to prevent such a hack, now.

The mudlib is designed to be very MudOS like btw. There is a file hierarchy just like any LP mud. Each creator will have their own realm. There are domains, special directories for commands and verbs, etc. The MUD starts, creates the master object and simul efun object and applies optional packages (domain stats, verb support, etc). Once initialization is done the master objects and efuns are sealed. The game optionally does the eplog/pre-loading like MudOS and opens the configured ports.

The mudlib objects should only have access to the external functions provided by the loader and efun proxy (e.g. no direct access to the compiler or the module cache).

The first is the ability to spoof privileges to give yourself "admin" access to the filesystem and corresponding game commands. In a traditional MUD, developers used to be organized by "domain", so that they had the ability to write to their own directory and whatever subdirectories they were actively working on (assigned to). Likewise, their objects would only function in their home room(s) and those areas. Putting things, such as new weapons that players would carry through the game world, into the system areas required higher level access.

The second was the ability to spoof the driver to grant yourself arbitrary filesystem access outside the game. Obviously that's worse, since you could write to anything the MUD account has privs to.

When most people talk about MUD security, they're usually talking about the former, since having a new wizard in training be able to wipe out the whole game is usually a bad thing.