Summary

The enableSharding built-in role does not grant the enableSharding privilege on the cluster resource { cluster: true }. As a result, users assigned the enableSharding role cannot run updateZoneKeyRange, even though that command is documented as requiring only the enableSharding privilege action.

Steps to Reproduce

1. Create a database user with only the MongoDB built-in enableSharding role on the admin database.
1. Connect to a mongos instance as that user.
1. Run:

sh.updateZoneKeyRange("db.collection", { key: MinKey }, { key: MaxKey }, "myZone")

1. Observe: MongoServerError: not authorized on admin to execute command

Expected Behavior

A user with the enableSharding built-in role should be able to run updateZoneKeyRange. The documentation for updateZoneKeyRange states the command requires the enableSharding privilege on the cluster resource.

Actual Behavior

Running rolesInfo with showPrivileges: true on the enableSharding built-in role reveals it only grants enableSharding on the namespace resource { db: '', collection: '' }, not on the cluster resource:

db.adminCommand({ rolesInfo: { role: "enableSharding", db: "admin" }, showPrivileges: true, showBuiltinRoles: true })
// privileges: [
//   {
//     resource: { db: '', collection: '' },
//     actions: [ 'analyzeShardKey', 'enableSharding', 'moveCollection',
//                'refineCollectionShardKey', 'reshardCollection', 'unshardCollection' ]
//   }
// ]
// Note: NO { resource: { cluster: true } } entry

Comparison to backup Built-In Role

The backup built-in role correctly defines privileges on both the namespace and cluster resources:

db.adminCommand({ rolesInfo: { role: "backup", db: "admin" }, showPrivileges: true, showBuiltinRoles: true })
// privileges: [
//   { resource: { db: '', collection: '' }, actions: [ 'find' ] },
//   {
//     resource: { cluster: true },
//     actions: [ 'appendOplogNote', 'getParameter', 'listDatabases', ... ]
//   },
//   ...
// ]

The enableSharding role should follow the same pattern and include an entry for {{{ resource:

, actions: [ 'enableSharding' ] }}} to be consistent with what updateZoneKeyRange requires.

Workaround

Users can create a custom role that explicitly grants enableSharding on the cluster resource:

db.adminCommand({
  createRole: "zoneKeyRangeManager",
  privileges: [{ resource: { cluster: true }, actions: ["enableSharding"] }],
  roles: []
})

Assigning this custom role in addition to the built-in enableSharding role allows updateZoneKeyRange to succeed.