Re: Thoughts on authoring support...

["Roy T. Fielding" <fi...@liege.ICS.UCI.EDU>]

A few thoughts.  First, I'm really glad you are looking into this,
since I think it is the next BIG feature worth supporting, and is
something I'll need to look into when I finally get around to doing
that dissertation thingy.

The W3C just started a working group on distributed authoring support;
I'd be more than happy to get you on that mailing list if you want.

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

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

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

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.

>    5) Unauthenticated PUTs should be flatly disallowed.  
> ...
> (5) is simple, and I hope, self-justifying; mod_auth_anon provides
> some kind of escape hatch for anyone foolish enough to *want* to allow
> any fool in the world to scribble all over their space.

I disagree here -- obviously that should be the default behavior, but
I see no reason to prevent people from setting up a truly anonymous
PUT-area for which they have no intention to ever check where the PUT
came from (in fact, for various legal reasons, do not want the ability
to find out where it came from).  Also, keep in mind that not all such
servers will be accessible to the "real net", and some sites could use
an internal server with no access control to build content for some
other, external server.

Most of the details you descibe are (b)-style checks.  My only useful
input there is to ask that the (a)-style checks don't get intermingled
with (b)-style mechanisms.

......Roy

Re: Thoughts on authoring support...

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

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 <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/