[SERVER-13080] Cannot run "copydb" within sharded cluster with auth enabled Created: 06/Mar/14 Updated: 10/Aug/18 Resolved: 10/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 2.4.9, 2.6.0-rc1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Shaun Verch | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
|||||||||||||||||||||||
| Operating System: | ALL | |||||||||||||||||||||||
| Steps To Reproduce: |
(note that both versions of "copyDatabase" shown above cause this to fail) |
|||||||||||||||||||||||
| Participants: | ||||||||||||||||||||||||
| Description |
|
The "copydb" command can be used to copy one database to another within a cluster. For a single node and a replica set, this is just the same node, but for a sharded cluster the target shard actually needs to run queries on the source shard to pull all the data for the database. The problem here is that the target shard fails to authenticate with the source shard. To fix this, I believe the "copydb" command needs to know whether it's copying from a node within a cluster or from another cluster, since the way it should authenticate is different in each case. |
| Comments |
| Comment by Maria van Keulen [ 10/Aug/18 ] |
|
Closing since the copyDB command was removed as of |
| Comment by Sherman Boyd [ 27/Feb/17 ] |
|
I'm pretty sure this issue affects version 3.0, 3.2 and 3.4. The documentation now states: "Do not use db.copyDatabase() from a mongos instance." Is this a 'wontfix'? |
| Comment by Amalia Hawkins [ 23/May/14 ] |
|
After this is fixed, we should reenable currently commented-out tests in jstests/auth/copyauth2.js and jstests/auth/lib/commands_lib.js/ |
| Comment by Shaun Verch [ 06/Mar/14 ] |
|
Confirmed that this bug exists in 2.4.9 and is not a regression. |