-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
Fully Compatible
-
v8.0
-
Cluster Scalability 2024-3-4, Cluster Scalability 2024-3-18, Cluster Scalability 2024-4-1, Cluster Scalability 2024-4-15, Cluster Scalability 2024-4-29, Cluster Scalability 2024-5-13, Cluster Scalability 2024-5-27, Cluster Scalability 2024-6-10
Several places in the mongod command handling check for authorization in addition to the checks for the command itself. Some of these checks seem unnecessary, in particular:
- Checking for internal auth in initializeOperationSessionInfo()
- This is only needed if internal session options are used, but is checked every time regardless.
- Checking for internal auth if an operation key was included in the request
- Operation keys are used to kill operations started by establishCursors (e.g. a find from a mongos), and can only be killed using the _killOperations command, which already requires internal auth, so checking when adding the keys seems unnecessary.
- If a client includes WriteBlockBypass metadata
- We require internal auth whether setting WriteBlockBypass to true or false, and mongos always sends this value, usually to false, so every request from a mongos has the extra check. It seems more reasonable to only check if trying to set WriteBlockBypass to true.
- When gossiping out $clusterTime when sending a request to another cluster node
- Cluster nodes always authenticate as __system and this user can always advance cluster time, so there's no need to check auth when gossiping out as part of egress commands.
- When gossiping out $clusterTime when sending a response back to a client that already was authorized to gossip $clusterTime in (same code as above)
- Generally clients will include $clusterTime in their requests to a server, which will be rejected with an error if the client isn't authorized to advance the logical clock. At the end of the request, we check again if that client is authorized to advance the clock to decide if they should receive $clusterTime, which checks the same privileges on the same operation context. If we can assume an operation context's authorization won't change over its lifetime (need to confirm this), then we can skip the second check.
- related to
-
SERVER-90944 Extend optimized auth checks for internal action type for sharded clusters
- Backlog