Re: [w3c/IndexedDB] Mark transactions inactive during key serialization (PR #479)

asutherland left a comment (w3c/IndexedDB#479)

Thanks for calling out other places where the spec converts a key to a value!  (And for filing the spec issue in the first place!)

For places like indexedDB.cmp and the IDBKeyRange methods (only/lowerBound/upperBound/bound/includes) where we don't have a transaction context to mark inactive and there's no complex state management going on it seems fine to not change the logic.

But for [continue](https://w3c.github.io/IndexedDB/#dom-idbcursor-continue) and [continuePrimaryKey](https://w3c.github.io/IndexedDB/#dom-idbcursor-continueprimarykey) we do explicitly have transactions and we do check that they are active and I think there is enough potentially interesting state management going on that it makes sense to consistently apply the same rationale we're using for add/put.  In particular, it seems like we could be in an upgrade transaction when calling one of the continue methods and then nefarious code could attempt to delete the object store or index that the cursor is against with that method on the stack.  I do think it's much less likely for code to be written in a way that could cause a security bug in this situation, but I do think it still applies that there's no reasonable use-case for content to be doing tricky things here and I do think it also simplifies things from a spec perspective.

For example, step 3 of both continue methods is to throw if the underlying source/object store has been deleted.  If we don't mark the transaction as inactive, then [deleteObjectStore](https://w3c.github.io/IndexedDB/#dom-idbdatabase-deleteobjectstore) currently is defined to synchronously delete the store; we "destroy store" without ever going "in parallel" or doing async hand-waving.  [deleteIndex](https://w3c.github.io/IndexedDB/#dom-idbobjectstore-deleteindex) also synchronously does "destroy index" although the 2nd para afterwards does do some hand-waving: "Although this method does not return an [IDBRequest](https://w3c.github.io/IndexedDB/#idbrequest) object, the index destruction itself is processed as an asynchronous request within the [upgrade transaction](https://w3c.github.io/IndexedDB/#upgrade-transaction)."  So we would side-step these edge-cases by making the transaction inactive during the key conversions.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/pull/479#issuecomment-3448547118
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/pull/479/c3448547118@github.com>