[SERVER-22039] printShardingSize command fails on not authorized in a sharded cluster with authentication enabled Created: 31/Dec/15  Updated: 03/Apr/23  Resolved: 30/Jan/18

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.6.11, 3.0.6, 3.0.8, 3.4.10, 3.6.2
Fix Version/s: 3.7.2

Type: Bug Priority: Major - P3
Reporter: Idan Sher Assignee: Blake Oler
Resolution: Done Votes: 1
Labels: neweng
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  1. Start a cluster with 1 to several shards, with authentication enabled and a user (--auth --username tmpuser --password 123456 ).
  2. Connect to the mongos instance using mongo shell:

    mongo localhost:27017/admin -u <admin_user> -p <password>
    

  3. Shard a collection - MUST

    sh.enableSharding("sampledb")
    sh.shardCollection("sampledb.samplecoll",{a:1})
    

  4. Switch to the DB and insert documents into it.commands:

    mongos> use sampledb
    for (var i =0; i<2000; i++){db.samplecoll.insert({a:i,b:i+2})}
    

  5. Run the printShardingSizes command

    mongos> printShardingSizes()
    

Output:

	{ "_id" : "sampledb", "partitioned" : true, "primary" : "shard01" }
		sampledb.samplecoll chunks:
			{ "a" : { "$minKey" : 1 } } -->> { "a" : 1 } on : shard02 {
	"errmsg" : "not authorized on sampledb to execute command { dataSize: \"sampledb.samplecoll\", keyPattern: { a: 1.0 }, min: { a: MinKey }, max: { a: 1.0 } }",
	"code" : 13

Sprint: Sharding 2018-02-12
Participants:
Case:

 Description   

Problem description

When running the command printShardingSizes, on a sharded cluster with authentication enabled, a "not authorized on <DB> to execute command

{ dataSize: \"sample.samplecol1\"}

..." error will appear.

mongos> printShardingSizes()
--- Sharding Status --- 
  sharding version: {
	"_id" : 1,
	"minCompatibleVersion" : 5,
	"currentVersion" : 6,
	"clusterId" : ObjectId("5685130fc895ab9401e7cc50")
}
  shards:
      {
	"_id" : "shard02",
...
...
...
  databases:
	{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
	{ "_id" : "sampledb", "partitioned" : true, "primary" : "shard01" }
		sampledb.samplecoll chunks:
			{ "a" : { "$minKey" : 1 } } -->> { "a" : 1 } on : shard02 {
	"errmsg" : "not authorized on sampledb to execute command { dataSize: \"sampledb.samplecoll\", keyPattern: { a: 1.0 }, min: { a: MinKey }, max: { a: 1.0 } }",
	"code" : 13
}

Hypothesis

The command wraps the dataSize command and executes it directly on the primaries of the shards, from the mongos, by connecting through the shell (without authentication). In the snippet of the code wrapped by the printShardingSizes command, the "mydb" variable attempts to connect directly to the primaries of the shards. As the authentication is enabled on the cluster level, the command itself fails on a "not authorized" error.

var mydb = shards[chunk.shard].getDB(db._id)
var out = mydb.runCommand({dataSize: coll._id,
          keyPattern: coll.key,
           min: chunk.min,
           max: chunk.max });

I have tested this scenario several times, on versions 2.6.11, 3.0.6 and 3.0.8. all with the same results.

Workaround

mongos> use sampledb
mongos> db.runCommand({dataSize:"sampledb.samplecoll",keyPattern:{a:1},min:{ a: MinKey },max: { a: MaxKey }})



 Comments   
Comment by Githook User [ 30/Jan/18 ]

Author:

{'email': 'blake.oler@mongodb.com', 'name': 'Blake Oler', 'username': 'BlakeIsBlake'}

Message: SERVER-22039 Fix printShardingSize command
Branch: master
https://github.com/mongodb/mongo/commit/784e55320f72ab9b9ec8b4f766d4be0c1b5e4a5b

Comment by jacky chen [ 30/Jan/18 ]

thanks for your reply.

I'm a new man for mongodb.
could you please share your script to build up sharding cluster.

Comment by Kaloian Manassiev [ 24/Jan/18 ]

Indeed the dataSize command is available on mongos, so there is no need to go through the shards and what vick.mena is proposing is correct. Given the simplicity of the fix, I am moving it to 3.7 Desired and will schedule it for the next couple of iterations.

Comment by jacky chen [ 15/Dec/17 ]

any correction plan for this issue?

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