You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pa...@softlanding.com> on 2005/11/01 17:38:06 UTC
Possible bug with svnserve and anon-access = write
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.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Possible bug with svnserve and anon-access = write
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 01 Nov 2005, Mark Phippard wrote:
> Paul Burba <pa...@softlanding.com> wrote on 11/01/2005 12:38:06 PM:
...
> > 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?
>
> I see the same problem with 1.3 RC 2 (on Win32).
>
> I have to configure the password DB, realm and also add a username and
> password. Then, I can do a mkdir/commit (after supplying credentials).
This sounds like the same issue that Philip just reported (Message-ID:
<87...@debian2.lan>).
--
Daniel Rall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Re: Possible bug with svnserve and anon-access = write
Posted by "Paul T. Burba" <pt...@adelphia.net>.
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 <pa...@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
Re: [PATCH] Re: Possible bug with svnserve and anon-access = write
Posted by Daniel Rall <dl...@collab.net>.
Paul, do you still think that this patch is necessary?
- Dan
On Tue, 01 Nov 2005, Paul Burba wrote:
> Paul Burba <pa...@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;
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
> _____________________________________________________________________________
Re: Possible bug with svnserve and anon-access = write
Posted by Mark Phippard <ma...@softlanding.com>.
Paul Burba <pa...@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?
I see the same problem with 1.3 RC 2 (on Win32).
I have to configure the password DB, realm and also add a username and
password. Then, I can do a mkdir/commit (after supplying credentials).
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Re: Possible bug with svnserve and anon-access = write
Posted by Paul Burba <pa...@softlanding.com>.
Paul Burba <pa...@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;
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org