View Issue Details

IDProjectCategoryView StatusLast Update
0000275Main CAcert Websitecertificate issuingpublic2013-01-14 10:39
ReporterSourcerer Assigned To 
Status closedResolutionfixed 
Fixed in Version2006 
Summary0000275: Race condition
DescriptionThere is a race condition in the code:

servercerts.php (and other files too):

                $ps = trim(`ps auxww|grep clientcerts.php|grep -v grep|wc -l`);
                $ps += trim(`ps auxww|grep servercerts.php|grep -v grep|wc -l`);
                if($ps > 1)
                        usleep(rand(90000, 100000));
        } while($ps > 1);

The problem is that as soon as 2 processes are waiting on a third one, they will never get active again, since one is always running.
Additional InformationSolution:
To start the lock:
$lck = fopen ("/tmp/SslLock", 'w');flock ($lck, LOCK_EX);

To end the lock again:
flock ($lck, LOCK_UN);fclose ($lck);
TagsNo tags attached.
Reviewed by
Test Instructions


duplicate of 0000204 closed Bad locking algorithm / DoS possible 



2006-07-31 23:43

manager   ~0000273

You shouldn't just call flock without any error handling. How do you know that the lock is set successfully? Do at least something like

  if(flock($lck, LOCK_EX)<0) sprintf("Couldn't set lock. Error: %d", errno);

and make sure someone/something is reading the output.

Sorry for removing the relationship to bug 202 but how do you think a deadlock may cause concurrency?


2006-08-01 04:56

developer   ~0000275

How about this instead of posting an error message...

        while(flock($lck, LOCK_EX) < 0)

As for the relationship to 202, I can't see how else the index.txt file is being corrupted like it does without some kind of race condition...


2006-08-01 08:08

manager   ~0000276

Well, putting the flock call in a while loop might cause process starvation, but this shouldn't matter too much in our case. At least the while loop wouldn't allow to issue any new certificates if the flock call fails so it would implement a basic error reporting as I requested.

But do you really think this is the proper way of debugging (and hopefully solving) the index.txt issue? I love Linux because in most cases there are many ways to find out why something is going wrong. Isn't the rootstore too important for such a trial and error solution? Who besides you has reviewed the real code used for the communication between server and rootstore?

And isn't it possible that you just overlooked something somewhere else? For example some cron job that for whatever reason is issuing certificates automatically?


2006-08-04 00:15

developer   ~0000292

If the flock calls solve the current problem of preventing a race condition we might as well close this bug, as for index.txt we might as well discuss that in bug 0000202 if they are seperate issues.


2006-08-13 10:16

administrator   ~0000373

The gpgcerts.php has not been fixed yet.


2006-08-13 10:55

developer   ~0000375

Guess the gpg bit was overlooked due to low demand and no problems was caused by it, but this is almost a separate bug since it won't conflict with openssl.

In any case I added extra code and the tarball has been updated.


2006-08-13 21:40

administrator   ~0000383

DonĀ“t we have to tunnel both X.509 and OpenPGP through the same serial cable, which can only be used by one request at a time?


2006-08-14 01:53

developer   ~0000389

The processes lock the serial device until a response is received, the other scripts wait for the device to become unlocked...

Issue History

Date Modified Username Field Change
2006-07-31 02:59 Sourcerer New Issue
2006-07-31 03:00 Sourcerer Status new => needs work
2006-07-31 03:00 Sourcerer Assigned To => duane
2006-07-31 03:22 duane Relationship added duplicate of 0000202
2006-07-31 10:45 bluec Relationship deleted 0000202
2006-07-31 10:45 bluec Relationship added duplicate of 0000204
2006-07-31 10:48 duane Relationship added duplicate of 0000202
2006-07-31 23:43 bluec Note Added: 0000273
2006-08-01 04:56 duane Note Added: 0000275
2006-08-01 08:08 bluec Note Added: 0000276
2006-08-04 00:15 duane Status needs work => solved?
2006-08-04 00:15 duane Fixed in Version => production
2006-08-04 00:15 duane Resolution open => fixed
2006-08-04 00:15 duane Note Added: 0000292
2006-08-04 00:15 duane Relationship deleted 0000202
2006-08-13 10:16 Sourcerer Note Added: 0000373
2006-08-13 10:17 Sourcerer Status solved? => needs work
2006-08-13 10:55 duane Status needs work => solved?
2006-08-13 10:55 duane Note Added: 0000375
2006-08-13 21:40 Sourcerer Note Added: 0000383
2006-08-14 01:53 duane Note Added: 0000389
2007-10-24 06:20 evaldo Assigned To duane =>
2007-10-24 06:20 evaldo Status solved? => closed
2013-01-14 10:39 Werner Dworak Fixed in Version => 2006