Called, from key_exists, scan_sorted_subkeys re-creates the sorted
subkeys record of the given key and then searches through it.
The race is that between creation and parsing of the sorted subkey
record, another process that stores some other subkey of the same
parent key will delete the sorted subkey record, resulting in an
WERR_BADFILE of an operation that should actually succeed.
This patch fixes the issue by wrapping the creation and parsing
into a transaction.
Michael
(cherry picked from commit
a752bbd10d661ebc93b8d51bd583eb62eb00ad18)
Fix bug #7314 (registry: creation of sorted subkey record is racy (not atomic)).
(cherry picked from commit
06d1aeb7b686b8b929cf9bff48aedc9dbb88b7c3)
if (state.scanned) {
result = state.found;
} else {
+ res = db->transaction_start(db);
+ if (res != 0) {
+ DEBUG(0, ("error starting transacion\n"));
+ goto fail;
+ }
+
if (!create_sorted_subkeys(path, key)) {
+ res = db->transaction_cancel(db);
+ if (res != 0) {
+ smb_panic("Failed to cancel transaction.");
+ }
goto fail;
}
+
res = db->parse_record(db, string_term_tdb_data(key),
parent_subkey_scanner, &state);
if ((res == 0) && (state.scanned)) {
result = state.found;
}
+
+ res = db->transaction_commit(db);
+ if (res != 0) {
+ DEBUG(0, ("error committing transaction\n"));
+ result = false;
+ }
}
fail: