[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn delete fails with "403 Forbidden" if root is not readable

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 16 Aug 2012 19:49:55 +0100 (BST)

Bert Huijben wrote:
> Following editor v2 (and v1), deletion of a child is changing the
> list of children in the parent directory and as such requires (at
> least) write access to the parent.

The editors don't control authorization.  The parent path may be
mentioned in an editor call, but that doesn't necessarily mean the
repository authorization code has to require authorization for that
path.

> What happens if paths to within multiple repositories are passed
> to the function? Was/is this supported?

Yes, it's supported: delete_urls_multi_repos() calls
single_repos_delete() once for each group of targets that are in the
same repository.

> Should the delete be handled atomically or not?
> (Atomic deletion requires rooting at a common parent)

A delete of targets in one repository should be (and is) atomic, using
'svn rm'.

From the point of view of driving a commit editor, yes we must root
the edit at a single common parent directory.  But this makes me
wonder, is the problem in fact lower down?  Like I said above, just
because the edit is rooted at a directory doesn't mean the repository
should require read authorization for that directory, if the edit does
not actually touch that path.

I'm now thinking the bug is in RA-neon or lower down.

- Julian

> Julian Foad wrote:
> [...]

>> I went looking at the Book and found nothing about what access
>> is required for a delete.  That's an omission we should remedy.
>> 
>> What is the correct authorization requirement for deleting a
>> node?  Read-write required on the node's parent directory and on
>> the node itself?  Only on its parent?  Only on the node itself?
>> Read access on the parent and read-write on the node?
> [...]
Received on 2012-08-16 20:50:33 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.