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 we're going to change the public API of the authz parser, we could
also add an equivalent of a -Werror flag to svnauthz. That could be
useful for scripts so that warnings don't get ignored. We could also add
such a flag to the parser itself, but I'm not sure how such a thing
could be used at the repository level.
-- Brane
Received on 2019-01-19 22:29:48 CET