You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/12/14 17:35:49 UTC
per-path authz and locking
I'm putting authz_read calls into mod_dav_svn's new locking functions,
so that we can continue the tradition of dealing with unreadable paths.
I'm not sure how mod_dav_svn should behave, though, in these scenarios:
* a request comes to LOCK/UNLOCK an unreadable file path.
What should mod_dav_svn return?
- "404 Path Not Found"?
- "403 Forbidden"?
- "401 Unauthorized"?
* a request comes in to discover an existing lock on an unreadable path.
What should mod_dav_svn return?
- "no lock present" (even if there is)
- one of the other three 4XX errors above?
* a request comes in to discover all locks below a directory path.
But some of those locked child-paths are unreadable. What should we
return?
- only the readable locked-paths (& locks) ?
- some sort of 4XX error?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: per-path authz and locking
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, December 14, 2004 11:35 AM -0600 Ben Collins-Sussman
<su...@collab.net> wrote:
> * a request comes to LOCK/UNLOCK an unreadable file path.
> What should mod_dav_svn return?
>
> - "404 Path Not Found"?
> - "403 Forbidden"?
> - "401 Unauthorized"?
Authorization/authentication should preempt the other error codes. 404 is
certainly incorrect. So, either 401 or 403 I think is correct. What do we
return if they try to GET an unreadable file path? I think we can be
consistent here.
> * a request comes in to discover an existing lock on an unreadable path.
> What should mod_dav_svn return?
>
> - "no lock present" (even if there is)
> - one of the other three 4XX errors above?
The same as above (401 or 403).
> * a request comes in to discover all locks below a directory path.
> But some of those locked child-paths are unreadable. What should we
> return?
>
> - only the readable locked-paths (& locks) ?
> - some sort of 4XX error?
Here, I think returning the subset of readable locked-paths is correct. They
wouldn't even be aware of the other paths: no sense to return them. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: per-path authz and locking
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> I'm putting authz_read calls into mod_dav_svn's new locking functions,
> so that we can continue the tradition of dealing with unreadable paths.
>
> I'm not sure how mod_dav_svn should behave, though, in these scenarios:
>
> * a request comes to LOCK/UNLOCK an unreadable file path.
> What should mod_dav_svn return?
>
> - "404 Path Not Found"?
> - "403 Forbidden"?
> - "401 Unauthorized"?
>
> * a request comes in to discover an existing lock on an unreadable path.
> What should mod_dav_svn return?
>
> - "no lock present" (even if there is)
> - one of the other three 4XX errors above?
>
> * a request comes in to discover all locks below a directory path.
> But some of those locked child-paths are unreadable. What should we
> return?
>
> - only the readable locked-paths (& locks) ?
> - some sort of 4XX error?
I think the answer depends on what this "unreadable file path" actually
is. If it's a file in the subtree of a no-access directory, then I think
the answer should be 404. It the file itslf is noaccess but the path is
not (i.e., the user can "svn ls" and see the file, but cant' read it),
then it should be 401.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org