At 10:05 AM 5/2/96 -0700, new-httpd@hyperreal.com wrote:
>Robert> One way out might be to reflect this distinction in mod_perl,
>Robert> allowing people to declare both "module-like entities" (which
>Robert> can do anything a C-coded module could do) and "script-like
>Robert> entities" --- with, of course, dramatically tighter
>Robert> restrictions on who can create the former and where the server
>Robert> would look for them.
>
>I think there are actually (at least!) 3 ways one would want to use
>Perl (or any embededded language):
>
>1. As an interface to the API, that is, a module

Yes.

>2. As a faster CGI.

Yes.

>3. As an interpreted server-side include

Hmm, hey, why not?

>
>For items #2 and #3, the code must be interpreted in some sort of safe
>compartment (Perl terminology -- Tcl has a similar notion).  As a
>webmaster you would like to open capabilities such as #3 up to your
>users, without sacrificing security.  Safe compartments are the way to
>go here.

We need to think about this.  By using Perl's Safe compartments, we can add
more security, but take away functionality.  Ah, trade-offs.  For some
people, just using -Tw makes them feel "safe".  Maybe a mod_perl_safe_cgi,
something like what Malcom Beattie did with "safecgiperl".  Here's a blurb
from that:

----
Restricted operators
--------------------

There are many Perl operators not available to the compartment in
which your CGI program is run. These mostly include operators which
provide access to the operating system. The following list is not
exhaustive but includes the most common excluded operators:
* system, `backticks`, exec, fork, syscall, signal handlers,
  pipes (including open(FOO, "|bar") and open(FOO, "bar|"))
* network access (socket, bind, connect, ...)
* File munging (rename, link, opendir, chown, ...)
* System V IPC (shared memory, message queues, semaphores)
* File tests (-r, -w, -l, ...)
* Calling perl on other files (require, use, do 'file')

Opening files for reading/writing is restricted. The "open" command
is subject to the following restrictions:
* Files opened for reading must be owned by the user.
* Files opened for writing must be opened by using a filename containing
  no "/" characters. The filename is taken to live in the directory
  ~/cgi/out and the file must already exist at the time the open is
  performed. It can be a symbolic link if desired.

----

>
>But a module written in Perl should have no such restrictions -- only
>the web admin should be able to install such code.
>
>Not everyone will want all 3 capabilities.  I'd ask that the mod_perl
>author(s) try to separate embedding Perl from the particular features
>of their module (which as I understand implements #1?), so that the
>others can be implemented as optional modules on top of the embedding.

OK, this sounds like the first vote in favor splitting into mod_perl,
mod_perl_cgi, mod_perl_whatever, of course while keeping *most* of the code
in one place, where the modules can share, that place being where it is now
in Apache.xs.  

>
>I'd also like to see mod_include extended so that an add-on can easily
>register a new include type (ie "perl" or "tcl").  Maybe I'll do this
>someday, we'll see.

Sounds cool to me!

-Doug

>
>Tom
>
>