The Lock Manager today relies on ResourceIds as the identifier for the lock acquisition.

We use this in order to first get the bucket to reduce mutex contention in the manager via LockBuckets as well as to do the actual MODE_* locks. The latter is critical in the sense that a particular ResourceId can only ever hold compatible lock modes and a strong MODE_S/X lock will cause all intent locks to wait behind for a particular ResourceId.

The security implication here is that an adversary could identify a collection that shares the same ResourceId as an internal one such as the oplog and force constant MODE_X acquisitions via index DDL operations. This would indirectly cause the internal collection to be unavailable due to not acquiring their intent lock.

This is safe in the case of the oplog since writes to it do not take any locks but for other collections this could become an issue if for example the adversary were to create a moderately large collection and do foreground index builds on it constantly.