Recording this for the benefit of anyone else who comes across this problem:

The Mac OS X Finder can act as a webdav client, allowing data exposed through a webdav interface to be mounted as an apparently native filesystem. This is how, for example, iDisk works.

WebDAV authentication is taken care of the same way as HTTP; for any given operation, the server can demand authentication, by returning a 401 error and requiring an authentication token from the client. This token can be of various forms, but the simplest is Basic authentication - a username/password combination.

And indeed, when you ask to mount a webdav filesystem protected by Basic authentication, Finder will pop up an appropriate dialogue box, and authenticate you.

However - HTTP authentication works per-operation, not per-server. That is, different resources on the same server can have different authentication requirements; indeed different operations on the same resource may have different requirements (for example, user A may be allowed to read and write, user B may only be allowed to read).

Finder doesn't completely understand this; or rather, the UI it presents to deal with this is broken. If you try and mount a directory, only some of whose sub-directories you have access to, then Finder will try and read all of the subdirectories. Given that you don't have access to everything it is trying to read, it will then conclude you don't have access to anything at all, and will only let you read any resources which are completely unauthenticated.

A temporary work-around is on the server to move any such subdirectories elsewhere, and put temporary HTTP redirects in place. This seems to quieten Finder down, and give the desired result. Unfortunately, it doesn't usefully scale where there are many such cases; nor where these permissions are liable to relatively frequent change.

As a result, it's essentially impossible to use Finder as a webdav client for a server with any complex ACL policy.

I've reported this to Apple as bug 5837223.