Committed in http://svn.apache.org/r1679181 (and r1679182 for CHANGES entry).
Backport to 2.4.x proposed in r1679183 (including Jan's r1663647).
On Tue, May 12, 2015 at 1:46 PM, Yann Ylavic <ylavic....@gmail.com> wrote:
> (CC'ing Michel, sorry for the resend, my initial omission)
>
> On Tue, May 12, 2015 at 10:41 AM, Yann Ylavic <ylavic....@gmail.com> wrote:
>> This as been raised on users@.
>>
>> ---------- Forwarded message ----------
>> From: Yann Ylavic <ylavic....@gmail.com>
>> Date: Tue, May 12, 2015 at 10:09 AM
>>
>> On Mon, May 11, 2015 at 10:54 PM, Michel Stam <mic...@reverze.net> wrote:
>>>
>>> I was tinkering over the weekend with mod_authz_dbd and mysql, and i could
>>> not get a RequireAny/RequireAll to match on multiple Require dbd-group
>>> statements.
>>> It would always match only the last result from the query, but once for
>>> every row in the resultset.
>>>
>>> Example:
>>> <LocationMatch "/(?<name>[^/]+)/">
>>> <RequireAny>
>>> Require user %{env:MATCH_NAME}
>>> Require dbd-group %{env:MATCH_NAME}
>>> Require dbd-group Administrators
>>> </RequireAny>
>>> </LocationMatch>
>>>
>>> After some searching, it appeared to me to be a regression of this:
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=46421
>>
>> The fix mentioned there is about APR's dbd (mysql) code but has never
>> been pushed to a release (the bugzilla report is still open).
>> As already discussed in [1] (with a simililar fix for mod_authn_dbd in
>> [2]), I don't think it should be addressed in APR though (but in httpd
>> as you and the OP of bugzilla #46421 proposed).
>>
>> There also seems to be other misuses of apr_dbd_get_entry() returned
>> values in httpd, I'll start a thread on the dev@ mailing-list and
>> propose a fix.
>>
>> [1] http://www.mail-archive.com/dev@apr.apache.org/msg26024.html
>> [2] http://svn.apache.org/r1663647
>>
>> ---------- End of forwarded message ----------
>>
>> The issue is that apr_dbd_get_row()'s entries (usually pointed to by
>> apr_dbd_get_entry(), depending on dbd though) get destroyed whenever
>> apr_dbd_get_row() returns -1 (no more rows in iterative mode).
>>
>> This seem to be the case for several dbd systems implemented in APR,
>> so I think we should take care of the entries' lifetime when used
>> after an apr_dbd_get_row() loop.
>> Thus, I think the attached patch should be applied, thoughts?
>>
>> PS: there are also APR dbd systems where the entries are duplicated on
>> the apr_dbd_results' pool, so APR is not really consistent...
