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

Re: [RFC] Authz_svn support for svnserve/file

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-05-02 07:56:48 CEST

On Sun, 2005-05-01 at 17:55, Marcus Rueckert wrote:
> I just wonder how much it would take to add authz_svn support to
> svnserve/file?

Mostly, I think it would be pretty straightforward:

  * Move the file-processing logic from mod_authz_svn to libsvn_repos.
libsvn_repos would not be doing any enforcement, just providing the
routines to parse and query an authz file. (There's an argument for
putting this in libsvn_subr instead, but I don't think it's a compelling
one.)

  * libsvn_repos already has callbacks to check read access during an
update etc.. Add similar callbacks to check write access in the commit
editor.

  * In svnserve, add calls to the new authz routines, through a
combination of the libsvn_repos callbacks and just calling to check (for
instance, check_path wouldn't rely on callbacks; it would just check).

There is some room for improved quality of implementation here; unlike
mod_authz_svn in its current form, we could add a way to distinguish
between "all authenticated users" and "anyone at all, authenticated or
not" (perhaps "*" and "**" in the authz file), and perform
authentication challenges when an anonymous user runs into a path they
can't access. However, that presents a bunch of technical hurdles. The
authz-processing routines would need to be able to query for whole
subtrees (which precludes ever adding wildcard support to the authz
file, I think) so that we can check in advance if an update can succeed;
and while the protocol allows a commit to do an authn challenge at the
end, when it knows all the paths which are to be modified, the code
would need to be restructured a bit to be able to perform that authn
challenge before finalizing the transaction.

So, probably best to punt on that part. If people want path-based
authorization for read access, for instance, they'll have to force all
users to authenticate for read access, and create a guest user.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 2 07:57:53 2005

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.