Bug 50773

Summary: Dav lock database corruption
Product: Apache httpd-2 Reporter: samuel.gallacier
Component: mod_davAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: REOPENED ---    
Severity: normal CC: wiml
Priority: P2 Keywords: PatchAvailable
Version: 2.4.4   
Target Milestone: ---   
Hardware: PC   
OS: All   
Attachments: Patch for httpd 2.2.17
perl script that demonstrates the bug
Patch for httpd 2.5.x-dev r1665752

Description samuel.gallacier 2011-02-14 12:10:20 UTC
Created attachment 26653 [details]
Patch for httpd 2.2.17

I have a database corruption (with error 500) if I do the following :
   - lock a collection with DEPTH Infinity and a Timeout (exemple 20 seconds) (the collection must have sub collections) : exemple : LOCK /myCollection/
   - Put a file in an existing sub collection of the locked collection (using a If header) : exemple : PUT /myCollection/mySubCollection/file.txt
   - Wait until the lock timeout is elapsed
   - lock again the collection : exemple LOCK /myCollection/
       => there we get an error 500

It's seem that the bug is comming from method dav_fs_get_locks in file modules/dav/fs/lock.c. When the lock is applicated to the new file (inherited from parent), the timeout is setted to 0 (because of partial request). Then when trying to lock again, the indirect lock of the file seem to be valid (no timeout) but the direct lock related is not.

I looked for a correction in httpd 2.2.17 (just by reading the sources) and I didn't found any.

When I change the sources like the patch in attachement, I have no error 500 any more.
Comment 1 TSS 2011-04-26 08:56:53 UTC
I can confirm that the corruption is easily reproducible when using apache dav along with a git repository. The issue easily appears when doing large commits witch take larger than usual amounts of time to process.
Comment 2 Wim Lewis 2013-04-17 01:57:58 UTC
Created attachment 30204 [details]
perl script that demonstrates the bug
Comment 3 Wim Lewis 2013-04-17 02:00:27 UTC
I can confirm that 2.4.4 still has this bug (I was hitting it fairly often in 2.2.2x as well). The following messages show up in the error log:

[Tue Apr 16 18:51:16.453337 2013] [dav:error] [pid 7513] [client] Could not LOCK /wiml/bugzilla50773/dirA/ due to a failed precondition (e.g. other locks).  [500, #0]
[Tue Apr 16 18:51:16.453347 2013] [dav:error] [pid 7513] [client] The locks could not be queried for verification against a possible "If:" header.  [500, #0]
[Tue Apr 16 18:51:16.453353 2013] [dav:error] [pid 7513] [client] The lock database was found to be corrupt. An indirect lock's direct lock could not be found.  [500, #402]

I've attached a simple perl script that causes the bug (it just follows the steps outlined in samuel.gallacier's comment).
Comment 4 Wim Lewis 2013-04-22 22:16:31 UTC
Apache trunk/2.5 r1470659 also still has this bug (the lock database is corrupted, although Apache does not necessarily crash any more)
Comment 5 Graham Leggett 2013-04-27 17:20:58 UTC
I have modified the patch so that it applies to trunk as follows, can you verify this fixes it for you?

Index: modules/dav/lock/locks.c
--- modules/dav/lock/locks.c	(revision 1476625)
+++ modules/dav/lock/locks.c	(working copy)
@@ -646,7 +646,8 @@
             ip->key.dptr = apr_pmemdup(p, val.dptr + offset, ip->key.dsize);
             offset += ip->key.dsize;
-            if (!dav_generic_lock_expired(ip->timeout)) {
+            if (!dav_generic_lock_expired(ip->timeout)
+                    && dav_dbm_exists(lockdb->info->db, ip->key)) {
                 ip->next = *indirect;
                 *indirect = ip;
@@ -847,6 +848,7 @@
         else {
             /* DAV_GETLOCKS_PARTIAL */
             newlock->rectype = DAV_LOCKREC_INDIRECT_PARTIAL;
+            newlock->timeout = ip->timeout;
         /* hook into the result list */
Comment 6 Graham Leggett 2013-04-30 12:17:49 UTC
Would it be possible to port the existing bugfix to httpd-trunk?

All bugfixes must be made to trunk before being considered for backport to v2.4 or 2.2.
Comment 7 Wim Lewis 2015-03-11 01:30:56 UTC
Created attachment 32557 [details]
Patch for httpd 2.5.x-dev r1665752

(In reply to Graham Leggett from comment #5)
> I have modified the patch so that it applies to trunk as follows, can you
> verify this fixes it for you?

This change works if I apply it to the implementation in modules/dav/fs/lock.c instead of (or in addition to) modules/dav/lock/locks.c --- there seem to be two nearly-identical copies of that code.

On the assumption that both copies have the equivalent bug, I've attached a patch against trunk based on yours / Samuel Gallacier's. This fixes the bug, at least as far as the perl-script testcase can tell.
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:25 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.
Comment 9 Christophe JAILLET 2018-11-09 21:11:34 UTC
Confirmed on 2.4.4 in comment 3.
Should be easy to reproduce with the provides test script (Thx for that)

So re-opening because likely to still be valid.