[SERVER-10750] Minimum roles required to run mongorestore with authentication Created: 11/Sep/13  Updated: 11/Jul/16  Resolved: 16/Oct/13

Status: Closed
Project: Core Server
Component/s: Tools
Affects Version/s: None
Fix Version/s: None

Type: Question Priority: Major - P3
Reporter: Siva Balasubramaniam Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on DOCS-1960 Document roles needed to use tools wi... Closed
Related
related to TOOLS-132 Mongodump and mongorestore without su... Closed
related to TOOLS-134 Mongodump and mongoexport should skip... Closed
related to SERVER-9514 System-defined roles Closed
Participants:

 Comments   
Comment by Siva Balasubramaniam [ 16/Oct/13 ]

Thank you. You may close this case.

-Siva

Comment by Spencer Brody (Inactive) [ 16/Oct/13 ]

As the reporter of SERVER-11199, you should automatically get email notifications of any activity on the ticket.

Cheers,
-Spencer

Comment by Siva Balasubramaniam [ 16/Oct/13 ]

Yes this is a request for the future. How would I know if the new feature requested is considered? Will I be receiving an email? You may close the case.

Thanks
Siva

Comment by Spencer Brody (Inactive) [ 16/Oct/13 ]

Great, glad the workaround is working for you!
I see that you filed SERVER-11199 as the feature request to make this better in the future. If you have no additional questions, I will go ahead and close out this ticket in favor of that one.

Cheers,
-Spencer

Comment by Siva Balasubramaniam [ 16/Oct/13 ]

Hi Spencer,
Your response was as below. You had suggested to write a script to copy only the collections, which I have tried and is working. We were told that we can request for an enhancement, that's why opened a case.
--============================================================================
Hi Siva,
Sorry about the confusion, I knew that dumping system.users would cause the dump to error out, but I had thought that we always tried to dump system.users last, after all normal collections, so the normal collection data would be dumped appropriately. Upon further investigation, however, I found that we do not do that - the collections are dumped in whatever order they show up in in the system.namespaces collection. My apologies again for the misleading information. We have an open ticket, SERVER-9012, which will make it easier to dump just the normal collections in a database, ignoring the users collections if you don't have access to read them. In the meantime, however, either the user performing the dump will have to have the userAdmin role so the user data can be read and dumped without issue, or you will need to dump each collection one at a time so that mongodump never tries to read system.users and error out. The latter approach could be scripted fairly easily by reading the contents of the system.namespaces collection (skipping the system.users collection and any entries with "$" in them, as those correspond to indexes, not collection namespaces) to get the list of collection names in the given database, then calling mongodump once for each collection.
--============================================================================

Thanks
Siva

Comment by Spencer Brody (Inactive) [ 16/Oct/13 ]

Hi Siva,
Have you had a chance to try out one of my suggestions?

Cheers,
-Spencer

Comment by Siva Balasubramaniam [ 20/Sep/13 ]

Thanks Spencer. Let me try it out.

-Siva

Comment by Spencer Brody (Inactive) [ 20/Sep/13 ]

Hi Siva,
Sorry about the confusion, I knew that dumping system.users would cause the dump to error out, but I had thought that we always tried to dump system.users last, after all normal collections, so the normal collection data would be dumped appropriately. Upon further investigation, however, I found that we do not do that - the collections are dumped in whatever order they show up in in the system.namespaces collection. My apologies again for the misleading information. We have an open ticket, SERVER-9012, which will make it easier to dump just the normal collections in a database, ignoring the users collections if you don't have access to read them. In the meantime, however, either the user performing the dump will have to have the userAdmin role so the user data can be read and dumped without issue, or you will need to dump each collection one at a time so that mongodump never tries to read system.users and error out. The latter approach could be scripted fairly easily by reading the contents of the system.namespaces collection (skipping the system.users collection and any entries with "$" in them, as those correspond to indexes, not collection namespaces) to get the list of collection names in the given database, then calling mongodump once for each collection.

Comment by Siva Balasubramaniam [ 18/Sep/13 ]

Hi Spencer,
I tried to do a mongodump giving the user dumptest1 minimum privileges "readWrite", based on what you have said, but was not successful. Not sure if I am going anything wrong or missing something.

--=========================================================================================================================================
Spencer Brody commented on SERVER-10750:
----------------------------------------

As an alternative, you could just give them readWrite, without userAdmin. This would allow them to dump/restore all the normal collections in the databases, but the information about the users defined in the database would not be dumped or restored. So then your application users could dump/restore their own data, but DBAs would still need to set up the user accounts on both the prod and dev systems.
--=========================================================================================================================================

Followed the steps below :
--==========================================================================================================
--Create a user dumptest1 in database testdb
MongoDB shell version: 2.4.5
Enter password:
connecting to: admin
eifdb1:PRIMARY> use testdb
switched to db testdb
eifdb1:PRIMARY> db.addUser(

{ user: "dumptest1", ... pwd: "dumptest1", ... roles: [ "readWrite" ] ... }

)

{ "user" : "dumptest1", "pwd" : "7a0ac2d62edc9d561033193e49dfde7d", "roles" : [ "readWrite" ], "_id" : ObjectId("5239ebe6b873e336be327629") } db.system.users.find() { "_id" : ObjectId("5239ebe6b873e336be327629"), "user" : "dumptest1", "pwd" : "7a0ac2d62edc9d561033193e49dfde7d", "roles" : [ "readWrite" ] }

--==========================================================================================================
--Inserted dummy data
mongo testdb -u dumptest1 -p
MongoDB shell version: 2.4.5
Enter password:
connecting to: testdb
5
--==========================================================================================================
--Using mongodump to dump the data
mongodump --out /info/mongodb_bkup/export_test --db testdb -u dumptest1 -p dumptest1
connected to: 127.0.0.1
Wed Sep 18 11:11:44.837 DATABASE: testdb to /info/mongodb_bkup/export_test/testdb
Wed Sep 18 11:11:44.837 testdb.system.indexes to /info/mongodb_bkup/export_test/testdb/system.indexes.bson
Wed Sep 18 11:11:44.837 3 objects
Wed Sep 18 11:11:44.837 testdb.system.users to /info/mongodb_bkup/export_test/testdb/system.users.bson
assertion: 11010 count fails:

{ ok: 0.0, errmsg: "unauthorized" }

--==========================================================================================================

Thanks
Siva

----Original Message----
From: Spencer Brody (JIRA) jira@mongodb.org
Sent: Monday, September 16, 2013 1:47 PM
To: Siva Balasubramaniam (sivkrish)
Subject: [MongoDB-JIRA] (SERVER-10750) Minimum roles required to run mongorestore with authentication

[ https://jira.mongodb.org/browse/SERVER-10750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=426421#comment-426421 ]

Spencer Brody commented on SERVER-10750:
----------------------------------------

As an alternative, you could just give them readWrite, without userAdmin. This would allow them to dump/restore all the normal collections in the databases, but the information about the users defined in the database would not be dumped or restored. So then your application users could dump/restore their own data, but DBAs would still need to set up the user accounts on both the prod and dev systems.


This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

Comment by Siva Balasubramaniam [ 17/Sep/13 ]

Thanks Spencer, let me give it a try. I will let you know the outcome.

-Siva

Comment by Spencer Brody (Inactive) [ 16/Sep/13 ]

As an alternative, you could just give them readWrite, without userAdmin. This would allow them to dump/restore all the normal collections in the databases, but the information about the users defined in the database would not be dumped or restored. So then your application users could dump/restore their own data, but DBAs would still need to set up the user accounts on both the prod and dev systems.

Comment by Siva Balasubramaniam [ 16/Sep/13 ]

Thank you Spencer. Essentially, DBA's should do the mongodump and mongorestore, to avoid giving admin privileges to regular users.

-Siva

Comment by Spencer Brody (Inactive) [ 16/Sep/13 ]

Yes, that is correct, although if listingprod and listingdev are the only databases in use in each system, you could probably get by with just readWrite and userAdmin on each.

Comment by Siva Balasubramaniam [ 16/Sep/13 ]

Say there is a PRODUCTION database listingprod and a DEVELOPMENT database listingdev. The databases are running on different systems. The user would like production data from listingprod into DEVELOPMENT database listingdev. Instead of DBA's doing the task of mongodump and mongorestore, we would like the user do their task themselves.
From what you said, the roles that need to be provided are readWriteAnyDatabase and userAdminAnyDatabase, which are pretty much ADMIN privileges.

Thanks
Siva

Comment by Spencer Brody (Inactive) [ 16/Sep/13 ]

Just to be clear, when you say you have PROD and DEV databases, are those the names of two databases in the same running mongod system, or are those two completely independent systems? If the former, then readWrite and userAdmin on the databases will be sufficient. If you mean that they are different clusters, however, then you will probably need readWriteAnyDatabase and userAdminAnyDatabase so that all databases in the cluster can be dumped/restored.

Please be aware that any user with userAdmin on a database can grant themselves any other role on that database, effectively giving them full admin access to that database. See here for more information about this: http://docs.mongodb.org/manual/reference/user-privileges/#userAdmin

Comment by Siva Balasubramaniam [ 16/Sep/13 ]

Thanks Spencer. We have authentication enabled on both PROD and DEV databases. We would like to give our database(from production database) users, privileges to export(mongodump) their database themselves and mongorestore to DEV database themselves, in this scenario, based on what you said, we would give our users "userAdmin" and " readWrite" privileges. Is this correct assumption?

-Siva

Comment by Spencer Brody (Inactive) [ 16/Sep/13 ]

The roles you need will depend on what data you are restoring.

If you are restoring just a single collection, you will need the readWrite role on the database being restored into. If you are restoring a whole database, and that database has users defined in it, you will need userAdmin on that database to restore the user definitions (as well as readWrite for the main data). If you are restoring a full system with multiple databases, you will need readWriteAnyDatabase and userAdminAnyDatabase.

That answer is all predicated on the assumption that you're talking about a version 2.4.x server and mongorestore.

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