Date: | Tue, 2 Oct 2012 22:24:21 -0500 |
Subject: | Race in kdb5_util load completion |
From: | Nico Williams <nico@cryptonector.com> |
To: | krb5-bugs@mit.edu |
If a kdb5_util load gets killed between rename()ing the new KDB file
into place and resetting the iprop ulog then the ulog can reflect the
pre-load state, which will almost certainly be incorrect.
This matters because we want to impose a timeout on full resyncs in
kpropd when iprop dictates that a full resync is needed, and the
simplest timeout scheme involves signaling the kdb5_util load process.
But also, we want no such races in general.
The fix is simple: re-initialize the ulog before renaming the new KDB
file into place, then proceed as usual. If the ulog is not properly
updated at the end of the load it will at least always result in
subsequent iprop get updates operations always indicating that a full
resync is required.
into place and resetting the iprop ulog then the ulog can reflect the
pre-load state, which will almost certainly be incorrect.
This matters because we want to impose a timeout on full resyncs in
kpropd when iprop dictates that a full resync is needed, and the
simplest timeout scheme involves signaling the kdb5_util load process.
But also, we want no such races in general.
The fix is simple: re-initialize the ulog before renaming the new KDB
file into place, then proceed as usual. If the ulog is not properly
updated at the end of the load it will at least always result in
subsequent iprop get updates operations always indicating that a full
resync is required.