Happy new year's everyone.

Obviously, I didn't drink enough as I woke up early and decided I wanted to revive an old idea I had a few years back… and perhaps put a new spin on it. The inside-out MUD. :)

The short version is, rather than making a server that tries to mimic the shell environment, handling user input, terminal support, command parsing, etc… why not just use the system for that? Why not give the users a bash-alike shell that talks to the server via a local socket (or named pipe even), but runs as a proper login shell?

The obvious main issue is security. You want the users to have the normal suite of player commands, but also you'd want your wizards to have editing commands and whatnot. That could be mostly handled by group permissions and sticky bits, I would think.

The next is protection from infinite loops in the shell itself, so folks can't use up your CPU by doing while(1) /bin/true or some such.

My question, and the reason I tossed this into the python area, is this? Does anyone use iPython, and how suitable would this be for such a task (opinion)?

I'd like to see a minimal example once you put something together. To me, it seems like the gains are offset by the onerous nature of trying to build something more restricted on top of what is basically a trusted user model. Perhaps if enough of the groundwork was done and a codebase (distribution?) was made that notion would disappear in my mind. I'm also curious about the scalability of such a thing vs the more traditional model for a mud.

Mooix: Where unix is the MOO
The New Adventure Shell
Mud-Shell

Runter, as far as the "restricted" vs. "trusted" nature… that's already in place via the unix group mechanism. chroot jails have been around for decades, and there's no reason to need more than a single jail. Players have the most restricted command set, able to issue any commands built into the shell, or that are owned by group player. Wizards get all the player group commands + building commands and access to some editors and other common unix tools. Admins might just get a regular bash shell and can choose to run the custom shell or work from a prompt.

It is slightly annoying without ACL's, as you have to ensure files created by the shell or by the game server have the right ownership so the right things can always write to them… but this isn't a new issue. LpMUD's try to get around the issue by using pathnames as security.

As for scalability.. how could it be any LESS scalable than the current system of stuffing everything into a single process?

Tyche, mooix seems closest to the idea. I swear I looked at this before, but maybe it was too long ago.. it certainly looks a bit further along than last time I checked.

You answer my question in your incredulous response. A single process could scale better than many. I suspect that at bare minimum you'd look at using many times more resources. A great example is how LP takes far more resources then a diku mud. Arguably, it does much more, but the diku retort may be that they didn't need more stuff being done. This seems to be even a bridge beyond the LP approach. Where very small components could require their own process. Read: overhead. Whether or not you don't care about this, because it's modular and awesome, that doesn't mitigate the circumstances around it requiring more resources manage. Some people may be interested in this being quantified.

Emacs is a great operating system. When I want a text editor, I use vim.

:devil:


(agreeing with Runter – scalability comes at a cost and you don't always need the benefit so the cost makes no sense)