Attempting to run a getMore command under a different logical session than the cursor was originally established under causes validateLSID() to uassert. This logic was originally added by SERVER-33367 as a safety check around cursors created inside of transactions. However, the changes from 965439 additionally restrict the __system user from running a getMore command under a different logical session even when neither the cursor nor the getMore command involve transactions.

The ability to use a different logical session would be helpful for internal applications such as the Backup Agent because MongoDB drivers do not expose an interface for explicitly specifying the logical session ID to a command.

There are authorization checks in the following locations separate from validateLSID():

• checkCursorSessionPrivilege() which requires the logical session ID saved in the ClientCursor object and the logical session ID of the command exactly match, UNLESS hasPrivilege((cluster, impersonate)) then it is ok if they don't match.
• validateAuthorization() which requires the authenticated user is co-authorized with the authenticated user saved in the ClientCursor object, AND the authenticated user still has the privileges required to run the original command saved in the ClientCursor object which created the cursor initially.
  • The co-authorization check would be expanded to accept the client having the impersonate privilege action as an alternative to having the same username.

To recap the intended work for this ticket:

1. Skip calling validateLSID() when the client has impersonate privilege action UNLESS one or both of opCtx->getTxnNumber() and cursor->getTxnNumber() are not boost::none. Attemping to use a cursor which was created inside of a transaction when the transaction resources were not unstashed by service entry point will likely lead to unexpected system behavior.
2. Enable clients with the impersonate privilege action to treat all cursors as their own in getmore_cmd.cpp.