I tried the suggested (not use LimitExcept but instead use Require
valid-user and satisfy any) but I am experiencing the same issue. The
svn copy command fails in the same way as before: first I see an
authorized copy with source = source and destination = destination
immediately followed (without any client secondary command or anything)
by a second copy of source = destination and destination = destination
where the user is '(null)' and authorization is denied, causing the full
attempted copy transaction to fail (not authorized).
Does any one have something similar to the following working?
- mod_davn_svn and mod_authz_svn
- SVN 1.3.2 (though also failed on 1.3.1 and 1.2.1)
- User authenticated by Apache mod_authz_ldap (configured to strip full
DN ... ie user uid=joesmith,ou=org,o=company gets identified in Apache
as user joesmith)
- Within mod_authz_svn, using groups to allow people like joesmith rw
perm to some sub directory (* = r is perm at / root)
I would think this would be a rather popular configuration with
companies using LDAP for authentication and that someone would have
encountered this.
Thanks,
Brian
Ben Collins-Sussman wrote:
> On 8/3/06, Brian Brophy <brianbrophy@email.com> wrote:
>> I really appreciate your follow-ups. Perhaps one additional thing I
>> should add is that we hope to be able to have a configuration that
>> permits anonymous read access, yet authorized write access. It is for
>> this reason that the "Require valid-user" occurs within the LimitExcept
>> ... so as to populate the Apache user for those operations where
>> mod_authz_svn's configuration would be looking to match the user to the
>> group in its file.
>
> The better way to do this is to *not* use LimitExcept at all, but
> instead to (1) unconditionally 'Require valid-user', (2) put a
> 'satisfy any' next to it, (3) unconditionally use SVNAuthzAccessfile,
> and (4) put a nice '* = r' on the root directory of your authz file.
> See example 6.3 in the svnbook.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 10 02:51:35 2006