httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: PUT handler spec?
Date Fri, 05 Jul 1996 18:44:14 GMT
  Is there a PUT method handler spec somewhere?  I would like to write
  something which did something intelligent with PUT requests.
[ I'm not reading all my mail over the holiday, but this caught my
  eye, so what the hey... ]

You could look at the PUT handling script that ships with apache-XX;
this is an experimental, buggy Perl script, which can run suid-root if
you want to risk that (subject to the usual restrictions on suid Perl
scripts, and see also below on known risks), which back-ends PUTs into
an RCS repository.  The directory containing the target file must
exist, and must have an RCS subdirectory containing a WEB.PUT.CTL file
which tells the put-handler under what circumstances it is allowed to
proceed.  Unfortunately, it's not documented more than that as of yet.

One thing I'm not comfortable with about this, BTW, is that the script
creates "giveaway chown" potential on systems that didn't have it
before the script was installed --- the attacker can play games
involving creation of links to a WEB.PUT.CTL file owned by the victim.
It's possible to tighten up the file-permission-checking rules hard
enough to take care of any such scenario I'm aware of (the script
would have to require the target directory, its RCS subdirectory, and
the control file to all be both owned by the same user, and writable
by nobody else), but I may still be missing a trick.

(NB the script, as shipped, relies on some experimental voodoo in the
server proper to leave the pid of the child process in a root-owned,
non-writable file, as at least a partial check on the validity of its
invocation --- this is the mechanism I threw out for discussion a
couple of weeks ago; I'm still not at all sure it's lock-tight, but
it's better than nothing.  If you want to run without this --- with a
standard Apache, for instance --- just comment out the call to the
check_server_child_status routine.  However, it is somewhat dangerous
to run the script suid without child checking, unless you feel
comfortable allowing users to fake up PUTs on each others' stuff).

This script needs to be activated by a 

   Script PUT /.../

line in the server's main config files.  The script itself must be in
a directory which has CGI-child-check turned on unless you've turned
off the checking in the script.  It seems to interoperate, for what
it's worth, with both Netscape Gold (gack) and GNN Press --- I
personally find the latter actually works a whole hell of a lot
better, but de gustibus.


PS --- if you look at the implementation of the server-side
   child-check support voodoo (apache-XX's util_child_check.c), you
   may notice the lack of any acknowledgment whatever in the code
   itself that it's running threaded.  Non-preemptive threading
   packages are kinda nice about letting you do things this way, but
   if anyone wanted to use this same stuff in a threaded server for,
   say, supporting a CGI-wrapper, it would probably start cutting
   badly into performance.  (I'm gambling PUTs are rare enough events
   that efficiency in handling them isn't of prime importance,
   particularly when the problems can only arise due to interference
   from multiple, simultaneous PUTs, but I can't be nearly so sure
   about wrapped CGI).

   These problems *don't* arise, of course, with the vanilla-1.1,
   standard pooled model...

View raw message