httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Kosut <>
Subject Re: Thoughts on authoring support...
Date Thu, 13 Jun 1996 03:52:40 GMT
On Wed, 12 Jun 1996, Roy T. Fielding wrote:

> Regarding the approach, I think it is important not to tie the server's
> PUT capability so close to the filesystem.  What I would expect is a
> layered security check, such as

Apache's current PUT capability fits is, in fact, about as far away
from the filesystem as you can make it. After having watched the
discussions about running an Apache that changes uids, I'm quite
confident it will be this way for some time, as if people don't trust
the server to change uids when it's *not* supposed to delete and
replace files, I imagine they'll be even more paranoid when it's
*supposed* to.

At any rate, Apache's current PUT (and DELETE, and POST for that
matter) support is (as I just said) probably as complete as it'll be
for a while. It lets you define a CGI script to handle PUT requests
(except when another CGI script is called), and that CGI script can be
anything the server admin wants it to be.

>     a) check that PUT is allowed for the requester (possibly authenticated)
>        on the requested URL, and also any limits like max-size or type;

The server can do the first part now, using <Limit PUT>. The second
part (size/type) could conceivibly be added into the servet core
without compromising any security (since it'd just be denying people).

>     b) check that the storage subsystem is PUT-writable by the webserver
>        for that area of storage.

Today, this could be done either by the server (if you're controlling access
with <Directory> directives), or by the PUT script (if you're
controlling access with <Location> directives).

> The first check needs to be independent of the filesystem to the same
> extent that our existing access control is (preferably more so, but that
> might require revamping access control entirely).  The second check
> needs to be storage-system dependent, but should at least have an
> abstract interface so that we can swap the filesystem with a DB or
> a version control manager without losing PUT capability.

Can do. In fact, there's no PUT capability to lose, just some hooks.

Alexei Kosut <>      The Apache HTTP Server

View raw message