[SERVER-26734] indexStats action is not sufficient privileges for $indexStats operator Created: 21/Oct/16  Updated: 16/Oct/21  Resolved: 27/Dec/16

Status: Closed
Project: Core Server
Component/s: Querying, Security
Affects Version/s: None
Fix Version/s: 3.2.13, 3.4.2, 3.5.2

Type: Bug Priority: Major - P3
Reporter: Adam Harrison Assignee: James Wahlin
Resolution: Done Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
is documented by DOCS-9463 Docs for SERVER-26734: indexStats act... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v3.4, v3.2
Steps To Reproduce:

1) Create user "test" with "dbOwner" role on a database
2) Use "test" user to create a role granting the "indexStats" action
3) Use "test" user to grant role from step 2 to "test" user
4) Attempt to use $indexStats on a collection

Sprint: Query 2017-01-23
Participants:

 Description   

Per the $indexStats documentation (https://docs.mongodb.com/manual/reference/operator/aggregation/indexStats/) : "If running with access control, the user must have privileges that include indexStats action."

A database user with "dbOwner" database privileges is able to grant themselves privileges which include the "indexStats" action in their respective database. These privileges do not allow the user to use the $indexStats aggregation operator.

// connected with "test_user" to "roles" db
db.getUser("test_user")
 
// User is a dbOwner in the "roles" database:
// {
// 	"_id" : "roles.test_user",
// 	"user" : "test_user",
// 	"db" : "roles",
// 	"roles" : [
// 		{
// 			"role" : "dbOwner",
// 			"db" : "roles"
// 		}
// 	]
// }
 
// Create role granting indexStats action
db.runCommand({ createRole: "index_stats_role",
  privileges: [
    { resource: { "db": "roles", "collection" : "" }, actions: [  "indexStats" ] },
  ],
  "roles" : []
})
 
// Grant role to user 
db.grantRolesToUser( "test_user", [ { "role" : "index_stats_role", "db" : "roles" } ])
 
db.getUser("test_user")
// User now has the role with the "indexStats" action:
// {
// 	"_id" : "roles.test_user",
// 	"user" : "test_user",
// 	"db" : "roles",
// 	"roles" : [
// 		{
// 			"role" : "index_stats_role",
// 			"db" : "roles"
// 		},
// 		{
// 			"role" : "dbOwner",
// 			"db" : "roles"
// 		}
// 	]
// }
 
// Exiting and re-connect 
 
// Try to execute $indexStats operator 
db.names.aggregate([ { "$indexStats" : { } } ] )
 
// Error: 
// 
// assert: command failed: {
// 	"ok" : 0,
// 	"errmsg" : "not authorized on test to execute command { aggregate: \"names\", pipeline: [ { $indexStats: {} } ], cursor: {} }",
// 	"code" : 13
// } : aggregate failed
// Error: command failed: {
// 	"ok" : 0,
// 	"errmsg" : "not authorized on test to execute command { aggregate: \"names\", pipeline: [ { $indexStats: {} } ], cursor: {} }",
// 	"code" : 13
// } : aggregate failed
//     at Error (<anonymous>)
//     at doassert (src/mongo/shell/assert.js:11:14)
//     at Function.assert.commandWorked (src/mongo/shell/assert.js:254:5)
//     at DBCollection.aggregate (src/mongo/shell/collection.js:1278:12)
//     at (shell):1:10
// 2016-10-18T16:33:56.028-0700 E QUERY    Error: command failed: {
// 	"ok" : 0,
// 	"errmsg" : "not authorized on test to execute command { aggregate: \"names\", pipeline: [ { $indexStats: {} } ], cursor: {} }",
// 	"code" : 13
// } : aggregate failed
//     at Error (<anonymous>)
//     at doassert (src/mongo/shell/assert.js:11:14)
//     at Function.assert.commandWorked (src/mongo/shell/assert.js:254:5)
//     at DBCollection.aggregate (src/mongo/shell/collection.js:1278:12)
//     at (shell):1:10 at src/mongo/shell/assert.js:13

However, a database user with the built-in "clusterMonitor" role is able to use the operator, as it has the "indexStats" action (https://docs.mongodb.com/v3.2/reference/built-in-roles/#clusterMonitor).

Can the "indexStats" action be assigned by itself, or must it be coupled with other actions? Ideally, I would like to be able to assign this privilege without offering all the permissions provided in the clusterMonitor role.



 Comments   
Comment by Githook User [ 13/Feb/17 ]

Author:

{u'username': u'ksuarz', u'name': u'Kyle Suarez', u'email': u'ksuarz@gmail.com'}

Message: SERVER-26734 indexStats action is not sufficient for $indexStats
Branch: v3.2
https://github.com/mongodb/mongo/commit/8e1842875126b5dbefee425d764819e01aa5f67a

Comment by Githook User [ 18/Jan/17 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-26734 indexStats action is not sufficient for $indexStats

(cherry picked from commit 67257272a057635640318842ea05b28e8499f71a)
Branch: v3.4
https://github.com/mongodb/mongo/commit/5dc3dac650f87a436fd6f8954bca581f9789f7f9

Comment by Githook User [ 27/Dec/16 ]

Author:

{u'username': u'jameswahlin', u'name': u'James Wahlin', u'email': u'james.wahlin@10gen.com'}

Message: SERVER-26734 indexStats action is not sufficient for $indexStats
Branch: master
https://github.com/mongodb/mongo/commit/67257272a057635640318842ea05b28e8499f71a

Comment by Kyle Suarez [ 21/Dec/16 ]

It appears that this was deliberately done as a part of SERVER-2227, though I agree we should fix it. Rather than requiring the indexStats action for all normal resources in AuthorizationSession::checkAuthForAggregate(), we should require it only for the target namespace of the aggregation.

Comment by Kelsey Schubert [ 16/Dec/16 ]

Hi aharrison,

Sorry for the delay getting back to you. We're able to reproduce this bug and will update this ticket as we work towards a fix. The issue is that currently the privilege check to execute $indexStats requires global privilege to execute this command on any database. As you correctly identify, you currently would need to use the built-in role "clusterMonitor" to execute $indexStats.

Kind regards,
Thomas

Comment by Adam Harrison [ 14/Nov/16 ]

Hi Ramon,

I just wanted to follow-up to see if you had any updates on this issue.

Thanks!

Adam

Comment by Ramon Fernandez Marina [ 24/Oct/16 ]

Thanks for your report Adam, we're investigating.

Generated at Thu Feb 08 04:13:03 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.