Fix repeated insertion of default attributes in SQLite DB#890
Fix repeated insertion of default attributes in SQLite DB#890cryingcatscloud wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTwo new PKCS#11 attribute type cases are added to the ChangesPKCS#11 Attribute Kind Mappings
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Simple but nice. |
This PR fixes repeated insertion of default attributes in the SQLite DB object store.
The DB backend was able to store CKA_PUBLIC_KEY_INFO and CKA_DESTROYABLE, but could not read them back because DBObject::attributeKind() did not classify these attribute types.
Observed with the DB object store:
After several object initializations, duplicate rows accumulated:
2|370|16
3|370|16
4|370|16
5|370|16
and:
2|297|16
3|297|16
4|297|16
5|297|16
The root cause is that P11Attribute::init() calls setDefault() when
osobject->attributeExists(type) returns false. DBObject::attributeExists() depends
on DBObject::accessAttribute(), which uses attributeKind(type) to decide which
attribute table to query. Since these two types returned akUnknown, the attributes
were never found, even though they were already present in SQLite.
At the same time, DBObject::setAttribute() could still insert them because it chooses
the table from the OSAttribute value type:
This made the DB backend repeatedly insert the same default attributes. It also breaks
read-only SQLite token databases, because even operations such as object lookup/signing
can try to initialize these default attributes and write to the DB.
The fix adds the missing mappings:
After this, DBObject can read back the attributes it stores, and repeated default
insertion stops.
Summary by CodeRabbit