Subject: Security 'n MOO 'n UNIX 'n stuff.

From: James Powell <[email-masked]>
Date: Thu, 7 May 1992 17:39:14 -0700

void *(*(*schlake())[])(void *); writes:
>I'm sure someone has.  I'm sure those people also realized what a *huge*
>security hole it would be, and how much it thrash the server if it was
>implemented in a "safe" way.

I wish I could believe it was such a completely rediculous proposition.

Mike O'Brien writes:
>        I'll admit I've given it some thought.  It brings up something MUDs
>haven't really dealt with in a big way in the past: system-wide security
>issues.  Suddenly you have to trust the MUD at the same level you trust the
>"Login" program.  Either that, or you have to arrange to run a local connection
>to the MUD as a shell, somehow.
>       Aside from that, it's an interesting idea.

Lots of programs must be trusted at the same level as login.

>[email-masked] writes:
>Hooks to run shell commands from the server are not a good idea.  Security
>risks are the biggest reason I'd never run a server with this feature
>(BUG!).  You are much better hacking your client to do this locally - it's
>hard to see why you need to use the server's resources to do this anyway.
>Many clients, in fact, already have this capability.

This MOO can't count on clients, but must provide UNIX services.  It is that,
or have UNIX provide MOO as a service.  Personally, I think your average
person would rather be faced with MOO with UNIX as an option rather than
UNIX as MOO with an option.

>Clay W. Luther writes:
>No, though we have thought about it.  However, judging from Pavel's opinion
>about extensions to moo, it would never be included in any of his upgrades.

That is too bad.  What is Pavel's policy about including extensions to MOO
in future releases?

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?
  -James-

---

From: Clay Luther <[email-masked]>
Date: Thu, 7 May 1992 17:48:45 -0700

> hacked the server: do you believe this would be a fairly simple mod?

It goes beyond simple.  It is trivial.
Really.

-- 
Clay W. Luther                  [email-masked]
System Manager                  Center for Network Neuroscience
University of North Texas       PO Box 5218 Denton, Texas 76203
817/565-3896,3472               aka. Malraux@GodNet (Bushashuru!)

---

From: Pavel Curtis <[email-masked]>
Date: Thu, 7 May 1992 18:46:14 -0700

Clay is confused and overreacting to earlier messages of mine.  I welcome
suggestions for server enhancements, all the more if they come with detailed
specifications and/or working implementations.  Even if you send me code,
though, and even if I agree that the provided functionality is a good idea, I
don't promise to use your code or even your interface to that functionality.  I
may think that there's a simpler or easier-to-use or more general way to get
the same effect.

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:
	+ The server will be doing nothing at all while the command is running,
	  including not running any other tasks.
	+ If the command takes more seconds than the current task has left,
	  then the task will immediately abort after the command finishes.
	+ There is no provision for giving input to the command or getting
	  output back.  One could, I suppose, take a list-of-strings argument
	  to system(), to be used as the standard input of the command, and
	  return a list-of-strings result, gathered from the standard output,
	  all this implemented by adding `< tmp-input-file > tmp-output-file'
	  onto the end of the command before passing it off to system(), but
	  this would only work at all reasonably for `batch-style' commands.
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
forked off in the background, input can be given to them in incremental bursts,
output comes in asynchronously either to a waiting task or by starting a server
task, etc.  While this is not particularly difficult in theory, it certainly
falls nowhere near `trivial'.

	Pavel