I'm now getting to the stage where most of authz in svnserve is ready
to rock. The only thing that now remains is to authz the commit
operations. So we need authz support in the commit editor.
This is all mostly straightforward: revv the commit editor API to take
an authz callback parameter or two, and get each editor operation to
do authz on paths it touches. Two points however that need
discussion:
* What happens when authz fails?
The corresponding editor operation returns
SVN_ERR_AUTHZ_UN(READABLE|WRITABLE). It is up to the editor driver to
decide what to do at that point. As far as svnserve is concerned,
such an error will abort the commit completely and return an authz
error to the client.
* How do we do recursive lookups?
The current svn_repos_authz_func_t, ie. the callback function
prototype for authz lookup functions, has no parameter to describe the
type of access required. This means one callback per kind of authz
lookup: one for read, one for write. But that means the commit editor
won't be able to ask authz to do a recursive lookup (unless we pass 4
authz callbacks to the commit editor, a total of 8 new parameters...).
The solution here is to revv the callback prototype and have it take
an extra REQUIRED_ACCESS parameter, whose value can be any mix of
read/write/recursive.
This prompts a policy question for me: How do we manage revving
callback APIs? The whole point of revving is that older programs can
keep on using the older APIs instead of the new ones. How can this
square when the revved API is a callback prototype? Do all functions
except the commit editor keep on using the old callback prototype to
preserve compatibility until a break is actually needed (at which
point the whole API gets revved)? I guess the latter makes sense as
it keeps compatibility with the old interfaces. But should then all
APIs using the authz callback get revved, so that the newer APIs all
use the same prototype rather than a mix of different revs of the
prototype? What is the official word on this?
If everyone is okay with those points, and once someone has helped
clarify the issues I have with the second, I'll get to implementing.
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 28 18:09:18 2005