SERVER-130139 added an authorization check for applyOps command ops (drop, dropIndexes, collMod, renameCollection) that resolve their target from the op's ui: the caller must be authorized for the collection the ui resolves to, not just the one named in o.

That check only runs when the oplog application mode is kApplyOpsCmd (repl/apply_ops.cpp). The mode is taken directly from the client-supplied oplogApplicationMode field of the applyOps command, and OplogApplication::parseMode accepts Secondary, InitialSync and Recovering. The applyOps command is the only caller of repl::applyOps, so a non-default mode is always client-chosen, and the gate lets any caller opt out of the check.

Preconditions: authenticated user with cluster applyOps + useUUID (e.g. restore, or a custom role) and rights on at least one collection to name in o.

Impact: same as SERVER-130139. The caller can drop, collMod or dropIndexes a collection they have no rights on, or rename it into a collection they can read.

Affected: every release carrying the SERVER-130139 fix: 7.0.40+, 8.0.29+, 8.3.8+, 9.0.0+, and master.

Steps to reproduce

Using the eveRole setup from jstests/auth/apply_ops_uuid_ddl_auth_divergence.js:

db.runCommand({
  applyOps: [{op: "c", ns: "db.mine", ui: <victim UUID>, o: {drop: "mine"}}],
  oplogApplicationMode: "Secondary",
});

Without oplogApplicationMode this fails with Unauthorized. With Secondary, InitialSync or Recovering it succeeds and drops the victim. The equivalent renameCollection op moves the victim's documents into the caller's collection. Verified on master.

Proposed fix

Call detail::checkAuthForUUIDTargetedCommand unconditionally, and add regression cases for each non-default mode to apply_ops_uuid_ddl_auth_divergence.js.