webDAV Access problems

I still don't understand why, even though realms were
set up to allow user gryphon browse and author
access, these didn't seem to apply when using webDAV.
But, it works again and that's the important thing.

I believe the reason is because WebDAV doesn't have control of the files until the group or owner is WWW. From that point, WebDAV uses the OD users/passwords to manage the realm. I'm far from an expert in this, but that's how I understand it.

Here's my understanding of things, based on quite a bit of configuration tweaks and tests over the last few weeks.

The 'browse' and 'author' permissions for WebDAV (the ones controlled in Server Admin -> Web -> Settings -> Sites -> (sitename) -> Realms) don't have anything to do with ownerships or permissions of files/folders created or modified on the filesystem. They are solely for determining what the HTTP client is allowed to do, based on the username that the client authenticates as.

If the client's request is allowed, any filesystem operations then carried out are subject to the user and group (and the umask) which the webserver process is running under. This is completely separate from the WebDAV realms. On the install here, httpd runs with user 'www' and group 'www' (this can be seen in the output from ps). So, when new files are created, they are consequently owned by user 'www' and group 'www'.

If any messages like 'Permission denied' occur in the webserver logs, the very first thing I would check is the ownership and permissions of the files, as viewed in a shell on the webserver itself (this is what Gryphon did when noting that existing files were owned by "gryphon:gryphon", and new files were owned by "www:admin"). If the webserver could not write to the files or directories it needs to, there's every chance this would manifest itself as strange errors like "The file could not be found" on a client mounting the WebDAV folder in a place like Finder.

Background:

I am running the web service on Mac OS X Server, as a staging area for edits to our organisation's live website. I need to allow clients to edit with several editors (Macromedia Dreamweaver, Macromedia Contribute, and NVU). I also use a hodge-podge of in-house software to help manage and post the content. Doing this kind of thing is absolutely guaranteed to provoke a whole host of permissions problems, unless there is a clear understanding of the permissions and authentication requirements of the webserver and the filesystem.

Extra point: permissions of newly created files by the webserver (as opposed to the ownership):

When using Macromedia Contribute to edit a page (via WebDAV), the file would be unwritable by group after it was saved. I would have to then 'chmod g+w' the file every time it was changed, so that my utility scripts could modify the file if they had to (I don't want to run them as user 'www'). This is because of the rollback feature in Contribute, which necessitates the creating of a new file; it wouldn't happen in Dreamweaver, as DW wasn't using rollback). (see http://www.adobe.com/go/tn_19176) Solution: changed the umask of the webserver process (this is done in the startup script which launches httpd - the implementation is left as an exercise to the reader). [Caveat: I would never do this on a webserver exposed to the Internet without throughly researching the security implications arising - and I probably just wouldn't. I only did this because the server is behind our organisation's firewall].

Mac Mini G4 1.25GHz Mac OS X (10.4.7)