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

Re: [PATCH] Re: Possible bug with svnserve and anon-access = write

From: Paul T. Burba <ptbsvn_at_adelphia.net>
Date: 2006-12-20 17:14:41 CET

Daniel Rall wrote:
> Paul, do you still think that this patch is necessary?

Dan,

Where'd you dig up that dinosaur? :-)

Anyway, it's not necessary, Philip independently came across the same problem
on the same day and suggested an alternative fix in a parallel thread:

http://svn.haxx.se/dev/archive-2005-11/0042.shtml

To save you from reading the thread, David Anderson (as the svnserve authz
author/guru) committed Philip's fix in r17150.

Paul B.

> - Dan
>
>
> On Tue, 01 Nov 2005, Paul Burba wrote:
>
>> Paul Burba <paulb@softlanding.com> wrote on 11/01/2005 12:38:06 PM:
>>
>>> While working on the ebcdic 1.3 port I found what I thought was a bug in
>>> our port code; but appears to be a general problem with svnserve in
>> 1.3.x
>>> RC2 when using anonymous write access.
>>>
>>> Using this simple two-line svnserve.conf,
>>>
>>> [general]
>>> anon-access = write
>>>
>>> write attempts to the repos produce an authentication error:
>>>
>>> svnadmin.exe create /SVN/REPOS/SVN_ANON
>>>
>>> svnserve.exe -d -r /SVN/REPOS
>>>
>>> svn.exe mkdir -m "make dir" svn://burba-397/SVN_ANON/DirB
>>> svn: Authorization failed
>>>
>>> As I understand svnserve authorization this should work; it does with
>> 1.2.
>>> Can anyone replicate this?
>>>
>>> Thanks,
>>>
>>> Paul B.
>> I looked at this some more and the problem appears to be in serve.c's
>> lookup_access. authz_check_access is called at the start, note it will
>> grant access by default if there is no authz-db file. Then in the last
>> conditional we demand that a username be present if one is required, ok,
>> that makes sense, but 1.2 and later clients *always* want a username (when
>> performing a commit anyway). So the following will always return FALSE
>> when a 1.2 or later client attempts commit via svn:// if no authz-db file
>> is present, even if blanket anon access is write:
>>
>> static svn_boolean_t lookup_access(apr_pool_t *pool,
>> server_baton_t *baton,
>> svn_repos_authz_access_t required,
>> const char *path,
>> svn_boolean_t needs_username)
>> {
>> enum access_type req = (required & svn_authz_write) ?
>> WRITE_ACCESS : READ_ACCESS;
>> svn_boolean_t authorized;
>> svn_error_t *err;
>>
>> /* Get authz's opinion on the access. */
>> err = authz_check_access(&authorized, path, required, baton, pool);
>>
>> /* If an error made lookup fail, deny access. ### TODO: Once
>> logging is implemented, this is a perfect place to log the
>> problem. */
>> if (err)
>> {
>> svn_error_clear(err);
>> return FALSE;
>> }
>>
>> /* If the required access is blanket-granted AND granted by authz
>> AND we already have a username if one is required, then the
>> lookup has succeeded. */
>> if (current_access(baton) >= req
>> && authorized
>> && (! needs_username || baton->user))
>> return TRUE;
>>
>> return FALSE;
>> }
>>
>> Paul B.
>>
>>
>> As best I can tell, this patch fixes the aforementioned problem.
>>
>> [[[
>> * subversion/svnserve/serve.c
>> (lookup_access): Don't check for username requirements if blanket access
>> is
>> granted and there is no authz-db file.
>> ]]]
>>
>> Index: serve.c
>> ===================================================================
>> --- serve.c (revision 16855)
>> +++ serve.c (working copy)
>> @@ -377,7 +377,7 @@
>> lookup has succeeded. */
>> if (current_access(baton) >= req
>> && authorized
>> - && (! needs_username || baton->user))
>> + && (!baton->authzdb || (! needs_username || baton->user)))
>> return TRUE;
>>
>> return FALSE;

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 20 17:55:44 2006

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.