httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@ai.mit.edu (Robert S. Thau)
Subject Re: Thoughts on authoring support...
Date Thu, 13 Jun 1996 21:15:51 GMT
  Can do. In fact, there's no PUT capability to lose, just some hooks.

Unfortunately, I've been putting off responding to Roy since some of
his concerns require a response at length, but I'd like to chip in now
with a quick "what he said" --- all I'm actually doing is hanging a 
script on Apache's existing hooks (specifically, the Script command in
Alexei's mod_actions code).

Be that as it may, I do understand why one might want to be concerned
with reusing as much of the code as possible if the system moved to
something other than the filesystem as a back end.  However, I just
looked over my play-test PUT-handler script, and once you take away:

  *) Permission checks and behavior which are inherently specific
     to a server which is using the filesystem as back-end storage
  *) Paranoia checks of various sorts which are applicable to more
     than just PUT-handlers (to data-type handlers, for instance)
     and which we might want to put in some sort of a library, but
     not one related to PUT-support per se
  *) Policy checks which Roy specifically objected to for one reason
     or another
  *) A little debugging code which I'd probably be getting out of a
     library myself if I had more of a clue ;-)

... there is literally nothing left to reuse.  (Well, maybe a 
copyright notice).

That, of course, does not justify the particular policy choices which
Roy (and Nathan, I believe) objected to --- in particular the apparent
blurring of the lines between Roy's class (a) and (b) checks,
regarding type checks on uploaded objects in particular.  That is what
requires the long-winded explanation which I haven't got time to type
right now.

The brief executive summary is that I don't want the PUT handler
uploading a CGI script, even if it believes in good faith that a web
server has asked it to do so, for the same reason I don't want it
overwriting /etc/passwd, even if it believes in good faith that a web
server has asked it to do so --- the risks of performing the operation
are just too great to allow it in the face of the possibility that the
web server has somehow been compromised or tricked into permitting an
operation that wasn't really authorized.  Furthermore, in case there's
any doubt about whether the uploading of a particular object should
be permitted or not, I want it to fail safe (i.e., reject the PUT).

As to *which* operations are too dangerous, my current theory is that
it's the ones you can't back out of --- i.e., that actually lose data
that the web server already had on the file system when the PUT
started, or risk substantial compromise to systems other than the web
server, e.g., password crack, running trojan-horse code, etc.  (These
criteria are also why I think it's important for the web server to
keep an audit trail and not delete or overwrite old versions --- in
combination, these things make ordinary PUT operations recoverable).
It ain't a perfect theory, but it's what I got, and I won't give it up
except for a better one.

(I recognize that checking uploads against a list of permitted types
in the back end is a kludge --- the error messages you get when the
checks fail say as much --- but I feel rather strongly that losing a
little elegance is an acceptable price to pay for a critical safety
check).

As I mentioned above, I've got more to say about all of this, but not
more time to say it in, so I'll leave it here for now...

rst

Mime
View raw message