Subject: <creeeeeek> the door opens a crack...

From: James Powell <[email-masked]>
Date: Fri, 8 May 1992 16:20:06 -0700

Well, here we go again!

Jeff d'Arcy <[email-masked]> writes:
>1. What we were originally talking about was a UNIX *command* level
>interface, not API level as you seem to be suggesting (I'm sure I don't
>need to ask that you correct me if I'm wrong).  There's a difference at
>both the conceptual and practical levels.

I am indeed interested in a command level (shell and beyond) door.

This certainly sounds like a step in the right direction:

Michael Richardson writes:
>  A co-process might be created in a chroot'ed environment to act as a
>process `server' --- open_network_connection() might be just what is
>really needed here. (perhaps an option to use an AF_INET socket
>instead thus guaranteeing security of this socket?)

But then again, so does this:

Mike Gallaher <[email-masked]> writes:
>There is a well-known way to provide access to external shells
>(command interpreters) in any moo, or any mud for that matter,
>with no server modifications.
>
>Write a program that logs into the moo as a player, and sits in
>a room waiting for people to come in and say, for instance,
>"ls", to which it would respond
>[ls response omitted]

And they are certainly different approaches.

David Bofinger <[email-masked]> writes:
>I'm sure Pavel has thought of this, around about three o'clock in the morning,
>just before he wakes up screaming in a cold sweat. What's the application,
>though? I can imagine it's a very general purpose change that will tend to
>accumulate applications with time, but it seems odd to me that nobody has
>mentioned what it would be used for. Knowing what the legitimate applications
>were would surely ease the security issues debate, once the Clay-Pavel flamewar
>has died down.

Hmm, ok.  The first two applications I need this for are newsreading and
error correcting file transfers.

Pavel Curtis <[email-masked]> writes:
>> James Powell writes:
>>  Anyway, ya'll can tell I'm not as concerned with the security aspects of the
>>  problem as I am with the implementation difficulties.  Those of you who have
>>  hacked the server: do you believe this would be a fairly simple mod?
>
>It depends upon the functionality you want to provide to the MOO programmer.
>In any case, I must disagree with Clay's characterization of the mod as
`trivial'.
>
>The simplest interface I can imagine is to reflect the ANSI C `system()'
>procedure in MOO as a built-in function.  That is, you could say
>	system("cp foo bar")
>to copy file `foo' to the new name `bar'.  The implementation in the server
>would be quite simple: it would simply turn around and call the ANSI C function
>and be done with it.
>
>Leaving aside issues concerning the environment in which such commands run
>(whose permissions, what working directory, etc.), there are several
>significant problems with this approach:
>[list of significant problems omitted]
>
>To my mind, even if the solution proposed in the third of these points was good
>enough for the application in question, the first two points would be fatal for
>any multi-user situation.
>
>To implement a more generally-useful solution, the server would need to provide
>functionality much like the GNU Emacs `subprocess' stuff, in which commands are
>[summary of GNU Emacs subprocess functionality omitted]

I'll need interactive 8-bit streams, so no system() approach is going to cut it.
It is looking like a pretty hairy project, but it is one that simply must be
done.  I would love to get comments on the suggestions from Mike Gallaher,
Michael Richardson, and Pavel, plus any additional ideas the MOO-crew
("Cowdependant no more!" - seen on T-Shirt) can put forth.  Thanks for your
interest in this problem, and your insightful commentary!
  -James-