User with `root` role cannot access config database

Ops and Admin
, ,
1

I’m trying to set up backups on a replica set using mongodump, authenticating with a user that has the root role, but I’m getting an error that suggests my root user doesn’t have permission to access the config database:

root@mongo-db1:/srv/mongo# mongodump --username=rcroot --password="secret" --out=/var/backups/20200925
2020-09-26T05:40:20.138+0000    Failed: error counting config.system.indexBuilds: not authorized on config to execute command { count: "system.indexBuilds", query: {}, $readPreference: { mode: "secondaryPreferred" }, $db: "config" }

If I log in to the mongo shell with that user, I find that indeed I cannot run the db.system.indexBuilds.count() command in config; I get an error indicating I’m not authorized. However, the user appears to have the root role:

rs0:PRIMARY> db.getUser("rcroot")
{
        "_id" : "admin.rcroot",
        "userId" : UUID("81fc86ff-6d12-4d23-83ab-7fc2591516a2"),
        "user" : "rcroot",
        "db" : "admin",
        "roles" : [
                {
                        "role" : "userAdminAnyDatabase",
                        "db" : "admin"
                },
                {
                        "role" : "root",
                        "db" : "admin"
                }
        ],
        "mechanisms" : [
                "SCRAM-SHA-1",
                "SCRAM-SHA-256"
        ]
}

This is mongod version 4.4, and my replica set is configured to use keyfile auth (in case that matters):

mongod --auth --replSet rs0 --keyFile /data/db/keyfile --enableMajorityReadConcern false

I’ve tried creating an entirely new user with the root role, but I get the same results.

I’m new to MongoDB, so I’m probably missing something silly…I’d appreciate any clues as to what it is!

2

This apparently is related to (or caused by) running mongo within a docker container. I was trying to run the mongodump command from the host machine, outside the container, and that’s when I got the above error. If I run the mongodump command from inside the container, it works fine and the rcroot user has the necessary permissions to complete the backup.

So I guess some kind of strange interaction is happening with docker. My docker-compose.yml:

version: '2'

services:
  mongo:
    image: mongo:4.4
    restart: unless-stopped
    volumes:
     - ./data/db:/data/db
     - ./data/dump:/dump
     - ./data/backups:/data/backups
    command: mongod --auth --replSet rs0 --keyFile /data/db/keyfile --enableMajorityReadConcern false
    ports:
      - "27017:27017"

The mongo instance is exposed from the container to the host on the standard port. Given that, I thought I’d be able to run the mongodump and mongo shell commands from the host. (And indeed, mongo works from the host for everything not requiring access to local or config databases.)

I can just run backup scripts from within the container, but I’m still curious about why this doesn’t work from outside.

1 Like
3

Thanks for sharing those findings.

4

Not sure how it is working on docker but i tried this from command line on my Windows host.Got the same error
It seems you have to give explicit privileges on system.collections
Even root user will not have access to some system.collections in config & local DBs
Did you try backup and restore roles?
Or create a custom role(readwrite on config db) and grant that to your admin user

5

Intrigued I also did a little test. I could not query the config.system.indexbuilds. But a dump completed successfully. Running mongodump from the 4.2 packages mongodump version: r4.2.8 gives the error @Matt_Winckler posted about.

mongodump from 4.4 packages dumps without error mongodump version: 100.1.1

So possibly a mongodump version mismatch ?

s0:PRIMARY> db.system.indexBuilds.find()
Error: error: {
	"operationTime" : Timestamp(1601224356, 1),
	"ok" : 0,
	"errmsg" : "not authorized on config to execute command { find: \"system.indexBuilds\", filter: {}, lsid: { id: UUID(\"c010c58f-7228-4489-a21e-f09066dfca42\") }, $clusterTime: { clusterTime: Timestamp(1601224356, 1), signature: { hash: BinData(0, A598E6347A1457E588869C023723BFEFA7D5DA1E), keyId: 6877201118682677249 } }, $db: \"config\" }",
	"code" : 13,
	"codeName" : "Unauthorized",
	"$clusterTime" : {
		"clusterTime" : Timestamp(1601224356, 1),
		"signature" : {
			"hash" : BinData(0,"pZjmNHoUV+WIhpwCNyO/76fV2h4="),
			"keyId" : NumberLong("6877201118682677249")
		}
	}
}
s0:PRIMARY> 
bye
root@85030c5e9a4a:/# mongodump --uri 'mongodb://admin:0o9i8u7y@mongo-1-a/?authSource=admin&replicaSet=s0'
2020-09-27T16:33:13.310+0000	writing admin.system.users to dump/admin/system.users.bson
2020-09-27T16:33:13.311+0000	done dumping admin.system.users (1 document)
2020-09-27T16:33:13.311+0000	writing admin.system.version to dump/admin/system.version.bson
2020-09-27T16:33:13.312+0000	done dumping admin.system.version (2 documents)
2020-09-27T16:33:13.312+0000	writing test.foo to dump/test/foo.bson
2020-09-27T16:33:13.313+0000	done dumping test.foo (4 documents)
6

The root role supposedly includes the backup role. (From what I was reading, this wasn’t always the case in previous versions, but it should be true in 4.4.) However, I did go ahead and try adding the backup role explicitly, and it made no difference.

7

aha, I think this is the winner! I had installed mongodump on the host machine via the Ubuntu mongo-tools package, and mongodump --version unhelpfully reports built-without-version-string.

So I copied the mongodump binary out of the docker container and tried running it on the host, and the backup then worked fine. Mystery solved!

Thanks Chris!

1 Like
8

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.