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.
As to the question of "can groups contain spaces?", I questioned this
also. I have tested that other non-COPY activities such as add, delete,
etc do successfully require the group to perform them as well as only
allow members of the group to do them ... so I am guessing the space is
ok. Additionally, in troubleshooting, I did just rename the groups to
have underscores instead of spaces and it did not change the behavior
nor the error messages in any way.
Regarding the "perhaps one request checks write perms on the copy target
and one checks read perms on the copy source" ... wouldn't "* = r" at
the root allow global read as it is not over-written below in the path?
Is it possibly an issue that it is trying to authorize the read and in
evaluating *=r it is not "grabbing" the user from Apache since it is *
or all and thus failing when it tries to match group membership? If
this were true, shouldn't it instead be doing something like: "if * is
allowed read, then grant read" ?
As you can imagine our goal is to allow read to all but modify/write to
only authorized group member's within a URI location (ie one group may
have write to /a/b/1 while another has write to /a/b/2 ... but /a on
down should be read to all).
Thanks again for your help!
Malcolm Rowe wrote:
> On Thu, Aug 03, 2006 at 02:10:04PM -0500, Ben Collins-Sussman wrote:
>> On 8/3/06, C. Michael Pilato <email@example.com> wrote:
>>> Just a guess: one request checks write perms on the copy target, one
>>> read perms on the copy source.
> Strange that we appear to check the target before the source. And the
> user appears to be in a group called 'repo_SVN Administrator' that has
> 'rw' on the repository root. (Can groups contain spaces?)
> Also, '*' has read access - is that 'all users' or 'all non-anonymous
> users' (I know, I should know that), it's the hypothesised read subrequest
> that appears to be failing.
>> ... and the GET subrequest (for the read check) has no username,
>> because of the <LimitExcept> block...
> Oh, I assumed the 'COPY' text in the log was the method used in the
> subrequest? The arguments in the subrequest certainly appear to contain
> both source and destination -- why would we generate two subrequests?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Aug 3 23:43:17 2006