[SERVER-29105] Make _mergeAuthzCollections ignore MaxTimeMS Created: 08/May/17 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | features we're not sure of |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Spencer Jackson | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Server Security
|
| Participants: |
| Description |
|
_mergeAuthzCollections is an internal command, which performs a very specific, and expensive, operation for mongorestore. mongos may attach a MaxTimeMS to this command, when it proxies it to the config servers. This can cause restoring many user documents to fail. Because _mergeAuthzCollections is internal, requires extensive privileges, performs an intentionally expensive operation, and failing due to timeout seems undesirable, it should ignore MaxTimeMS. |
| Comments |
| Comment by Spencer Brody (Inactive) [ 12/May/17 ] |
|
I think the better solution would be for mongos to not always send maxTimeMs for _mergeAuthzCollections, but I'm not sure how easy that is to do with the current sharding code. Last I was aware we were adding maxTimeMs to every command sent to the config servers no matter what at a pretty low level that would be hard to circumvent, but I know the sharding team's been touching that code a bunch recently so perhaps it's gotten easier now. |
| Comment by Andy Schwerin [ 09/May/17 ] |
|
I'd like to discuss this. I'm not thrilled by commands deciding they're too important to ignore maxTimeMS, and would like to understand the scenario better. |