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

Re: [PATCH] svnserve per-user read/write access control

From: Alec Thomas <subversion-list_at_swapoff.org>
Date: 2004-09-08 16:18:16 CEST

On Tue, Sep 07, 2004 at 12:14:28PM -0400, Greg Hudson wrote:
> Hm. While cleaning up the patch I noticed a couple more nits (wrong
> indentation style, and you could have grabbed the per-user default
> before computing result) and, unfortunately, a design problem:
> svnserve calls get_access() in several places to find out what access
> the client connection *would* have given that it is authenticated or
> unauthenticated: in send_mechs() to determine what mechanisms to
> present, in auth() to determine what mechanisms to recognize, in
> must_have_write_access() to determine if authenticating would grant
> write access, and in find_repos() to determine whether to reject all
> connections to the repository. If the level of access depends on
> *which* user the connection authenticates as, then we need a way of
> answering the question, "what's the maximum level of access any user
> could get by authenticating?" That's clearly not a five-line change any
> more.

Hmmm, yes, I see what you are saying. The reason I had never encountered
this is that all my Subversion instances run over svn+ssh where the user
is already known. In this situation it works quite well, but I should
have more thoroughly tested it under different scenarios.

As the patch is likely to be superseded by path-based access control, I
won't attempt to modify svnserve any further and I'm happy to continue
applying this patch to my local builds to give my fine control over
svn+ssh access.


Evolution: Taking care of those too stupid to take care of themselves.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 8 16:18:43 2004

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.