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

Re: SVN 1.10 AuthZ file parsing too strict?!

From: Branko Čibej <brane_at_apache.org>
Date: Tue, 22 Jan 2019 15:54:40 +0100

On 19.01.2019 22:24, Branko Čibej wrote:
> On 18.01.2019 23:07, Doug Robinson wrote:
>> Honored committers (and the rest of us):
>>
>> It's come to my attention that if a group is defined in an AuthZ
>> file without an associated account that SVN is, as of 1.10, generating
>> an error and failing to allow the use of that AuthZ file.
>>
>> Example:
>>
>>     [groups]
>>     goodGroup = acct1
>>     goodGroup2 = acct1, acct2
>>     badGroup =
>>
>>     [repoName:/someplace]
>>     @badGroup = rw
>>
>>     svnauthz: E220003: Error while parsing authz file: ...
>>     svnauthz: E220003: Access entry refers to undefined group ...
>
> Thinking about this some more: If we add a warning callback to the
> parser (I have that implemented locally), we may as well relax the
> requirement for a group being /defined/, not just non-empty. For
> example, this authz file will also fail to parse with the same error as
> shown above:
>
> [/]
> @nosuchgroup = rw
>
>
> and this one will also complain about an undefined group, but with a
> different message:
>
> [groups]
> somegroup = @nosuchgroup
>
>
> In both cases, instead of exiting with an error, just ignoring the ACE
> or group membership wouldn't affect the semantics of the authz file. If
> we can print warnings about such issues in 'svnauthz', users would still
> have a way to find such bugs in their authz files.
>
> Relaxing the restrictions on undefined groups (and maybe aliases, too?)
> would be a change for the next minor release.
>
> Thoughts?

If no-one has an opinion, I'm going to do this (closing #4803) and also
fix #4794 in the same way.

-- Brane
Received on 2019-01-22 15:54:50 CET

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.