[SERVER-8221] Using copyDatabase to copy from an unauthenticated instance to an authenticated instance fails Created: 17/Jan/13  Updated: 10/Dec/14  Resolved: 22/Mar/13

Status: Closed
Project: Core Server
Component/s: Admin, Security
Affects Version/s: 2.2.1, 2.2.3, 2.4.0-rc1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Mark T Assignee: Spencer Brody (Inactive)
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

MongoDB shell version: 2.2.1
Ubuntu 12.04.1 LTS


Issue Links:
Duplicate
duplicates SERVER-8280 copydb command always requires creden... Closed
Related
related to SERVER-7864 Make copyDB, cloneDB, etc. work with ... Closed
related to SERVER-8213 Make copyDB and clone work with auth ... Closed
Operating System: ALL
Steps To Reproduce:

1. Log into an authenticated server
2. Provide authentication creds
3. Attempt to run command "db.copyDatabase("dbName", "dbName2", "unauthed-db-location")

Results in:

Thu Jan 17 15:40:59 DBClientCursor::init call() failed
Thu Jan 17 15:40:59 query failed : admin.$cmd

{ copydb: 1.0, fromhost: "dev-shard1-n2.llnw.com", fromdb: "prep-dev", todb: "prep-dev" }

to: 127.0.0.1:27017
Thu Jan 17 15:40:59 Error: error doing query: failed src/mongo/shell/collection.js:155
Thu Jan 17 15:40:59 trying reconnect to 127.0.0.1:27017
Thu Jan 17 15:40:59 reconnect 127.0.0.1:27017 failed couldn't connect to server 127.0.0.1:27017

Participants:

 Comments   
Comment by Spencer Brody (Inactive) [ 21/Feb/13 ]

On the 2.4.0 release candidate this fails without an error message:

db.copyDatabase('test','test2','ubuntu:12345')
{ "ok": 0, "errmsg": "" }

and there is a message in the target DB's log saying:

Thu Feb 21 17:55:19.495 [conn1] replauthenticate: requires internal authorization, failing

Comment by Spencer Brody (Inactive) [ 21/Feb/13 ]

in 2.2.3, rather than crashing the target (authenticated) instance, you get back:

db.copyDatabase('test','test2','ubuntu:12345')
{
	"errmsg": "exception: can't open a database from a nested read lock local.",
	"code": 15928,
	"ok": 0
}
 

Comment by Spencer Brody (Inactive) [ 21/Feb/13 ]

Reproduced the problem with 2.2.1. The source database doesn't have to be sharded - the important thing is copying from an unauthed instance to an authenticated instance.

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