[SERVER-40660] Multiple indexes via createIndexes could bypass index limits Created: 15/Apr/19 Updated: 29/Oct/23 Resolved: 10/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.12 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Dianna Hohensee (Inactive) | Assignee: | Gregory Wlodarek |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Storage NYC 2019-05-20 |
| Participants: |
| Description |
|
It looks like if multiple indexes are requested via a single createIndexes cmd, we can incorrectly build indexes that exceed the allowable number for various reasons. For example, IndexCatalogImpl::_doesSpecConflictWithExisting will check that we are not exceeding the _maxNumIndexesAllowed setting. However, suppose the max is 5, the collection has 4 indexes and a createIndexes cmd requests 2 more indexes. Then we will run IndexCatalogImpl::_doesSpecConflictWithExisting on both index specs, it'll pass, and we will go build 2 more indexes – this is because neither index is part of the index catalog yet. It looks like we could bypass the subsequent text index limit check, too, if a caller specified two text indexes in one createIndexes cmd. |
| Comments |
| Comment by Githook User [ 10/May/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Dianna Hohensee (Inactive) [ 09/May/19 ] |
|
It looks like we get passed the check here in create_indexes.cpp, but then in multi_index_block.cpp we serially validate and register index specs, so we do catch it eventually. We get passed the first check because nothing is registered at that point. |
| Comment by Eric Milkie [ 09/May/19 ] |
|
Why were you unable to reproduce it – is the ticket description incorrect in some way? |
| Comment by Gregory Wlodarek [ 09/May/19 ] |
|
I wrote a test to verify this and was unable to reproduce it. We'll proceed with committing a jstest to ensure this doesn't become a problem in the future. |