gniibe at fsij.org
Thu Jun 9 10:12:44 CEST 2016
In the issue 1675, we handle trustdb locking:
I had identified a race condition for creation of trustdb.gpg. This
was fixed last year. However, the problem of trustdb corruption has
not gone yet.
This week, I looked through the code (trustdb.c and tdbio.c), and I
found that we have more places to lock the write access.
Even if we consider the write(2) for the record can be atomic, we have
The serialization of newly creating trustdb.gpg in the function
tdbio_set_dbname (tdbio.c). <--- last year's fix.
(2) BEING ANALYZED
The serialization of newly creating hash table in the function
create_hashtable (tdbio.c). <--- I think this is the issue now.
When two processes race for the position of end of file by lseek
(db_fd, 0, SEEK_END), it might result corrupted trustdb. A
process which comes later will also create a record for hash table
at the end of file at later time, but the block will be
overwritten by another process which comes first.
(3) The serialization of appending a record of RECTYPE_HLST in the
function upd_hashtable (tdbio.c).
(4) The serialization of creating a record of RECTYPE_TRUST in the
function tdb_update_ownertrust, update_min_ownertrust and
(5) The serialization of creating a record of RECTYPE_VALID in the
function update_validity (trustdb.c).
More information about the Gnupg-devel