More CGI Comments

rst@ai.mit.edu (Robert S. Thau)
From: rst@ai.mit.edu (Robert S. Thau)
Date: Tue, 11 Jan 94 13:57:52 EST
Message-id: <9401111857.AA09878@volterra>
To: rhb@hotsand.att.com
Cc: www-talk@nxoc01.cern.ch
In-reply-to: rhb@hotsand.att.com's message of Sun, 9 Jan 94 20:04:00 EST <9401100104.AA07753@hotsand.dacsand>
Subject: More CGI Comments
Content-Length: 4344

   From: rhb@hotsand.att.com
   Date: Sun, 9 Jan 94 20:04:00 EST

[ Back from the NSF site visit... ]  Here are a few gut-level responses to
Rich's proposal.  I've posted what amounts to a proposal of my own, in the
form of the documentation for the changes I've made to the server, which
I'll forward along under separate cover.  Here's some comparison between
mine and Rich's...

   Based on some limited discussion here, I propose the following: 

   Add to the srm.conf file:
   ***************************

   # UserExec: Whether local user executables is activated
   # 

   UserExec True
   ***************************

   Add a .srm_conf file in the users public_html directory
   (or whatever it's set to in the server's srm.conf file)
   ***************************

   # ScriptAlias: This controls which directories contain server scripts.
   # Format: ScriptAlias fakename realname

   ScriptAlias /cgi-bin /home/rhb/myscripts

The net effect of this, if I understand it right, would be to designate
certain directories as all-script and others as all-file.  It may be
simpler to just add an Allow attribute to the .htaccess files, so that a
.htaccess file with "Allow Scripts" in it would enable execution of scripts
from the directory containing it, and any subdirectories.  This also would
ease the load on the server a bit --- it's looking for .htaccess files
anyway, while it is not yet looking for .srm_confs as well.  Then again,
I'm biased ;-).

At any rate, that's why I added the attribute to the .htaccess files,
rather than adding code for an entirely new config file.

   #and possibly a line that includes info on how I identify 
   #my executable files

   ExecAlias magic, suffix=exe
   ***************************

   One point brought to my attention is that all directories are already
   "executable" in the NCSA server environment via the <inc var> directive
   (i.e., this takes care of my original problem of getting to the
   user variable in authentication), but it doesn't take care of things
   like forms.

   Now a more general question that turns the previous question inside
   out.  The original concern was in adding executables to directories
   that were not indicated as having executables.  Well it seems that
   I can certainly have "regular" (non script) html files in executable
   directories.  What do I gain from having a directory "not executable"?
   Why aren't all directories cgi-bin directories?  I can restrict
   GET in the directories in which I really have scripts if I'm concerned
   about reading scripts...

In fact, that's basically the situation that I've got here --- all
directories are, at least potentially, cgi-bin directories (modulo the
trivia which I discuss under "compatibility").

Briefly, what you might gain from having a directory "not-executable" is
that if the directory is controlled by people you don't trust, they can't
screw you over as much.  Universities with a large population of
potentially hostile undergraduates are the classic example.  This is why
the NCSA server allows the adminstrator to control use of server scripts,
for instance, which (as you point out) raise many of the same security
issues.

   This in fact points up the need to have a "smart" server.  It is important
   that the server be able to identify the files it's serving not just by their
   suffix (i.e., in the mime type file) but via any available attribute
   (such as magic numbers).  The information that's available differs
   among platforms and application (server) needs.  I'm in agreement that
   we need a flexible method that allows the server to use it's "smarts"
   and the users' needs (e.g., the scripts I am interested in providing
   are all perl and tcl, so the #! would work for my application...).

It's certainly true that in the best of all possible worlds,
metainformation such as script-ness and MIME type would be represented
explicitly.  Gopher servers do this, for instance --- and explicitly
maintaining all the metainformation, and keeping it in synch with the files
themselves, turns out to be something of a chore.  The trick is to come up
with a scheme which is as simple and maintainable as the hack of
overloading this information onto file names (which is admittedly ugly, but
time-honored --- going back to 1963 at least).

   Rich

rst