[SERVER-8213] Make copyDB and clone work with auth when using new-style users Created: 17/Jan/13  Updated: 30/Oct/15  Resolved: 28/Oct/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.4.0-rc0
Fix Version/s: 2.5.4

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

Issue Links:
Depends
Duplicate
is duplicated by SERVER-9585 copydb command doesn't support role b... Closed
Gantt Dependency
Related
related to SERVER-7864 Make copyDB, cloneDB, etc. work with ... Closed
is related to SERVER-8221 Using copyDatabase to copy from an un... Closed
is related to SERVER-9093 Make copydb command work with auth on... Closed
is related to SERVER-11027 not authorized to execute repairDatab... Closed
Operating System: ALL
Participants:

 Description   

If using extended-form privilege documents it is impossible to run the copyDB and clone commands if auth is enabled. See the discussion in SERVER-7864 as to why this is hard to fix.



 Comments   
Comment by auto [ 28/Oct/13 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}

Message: SERVER-8213 Make copyDB and clone work with auth when using new-style users
Branch: master
https://github.com/mongodb/mongo/commit/0e35f9154fe51586d4bbc30267772a664b8df907

Comment by auto [ 06/Sep/13 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}

Message: SERVER-9517 SERVER-8213 Temporarily disable copydb tests that use auth until the copyDB command works with new roles
Branch: master
https://github.com/mongodb/mongo/commit/b9a1874e3e839aa130fe73d112470debb33e59b8

Comment by Spencer Brody (Inactive) [ 23/Apr/13 ]

Proposed plan:

copyDatabase is the only one that could work when the source server is outside the current cluster and has auth enabled, because it's the only one that takes a username and password argument.
clone could work if the source is on the same machine, or if the source doesn't have auth on.
cloneCollection could work if the source machine doesn't have auth on (it doesn't support a local source).

It is easy have have all 3 require whatever privileges they need to write to the target (which is the machine that the commands are run on), the problem is for when the source for clone or copyDatabase is part of the same cluster, you need to also require the necessary source privileges. Plan is first check if the source is the current machine (there's an easy way to do this by calling HostAndPort::isSelf), and if not, to then create a new connection to the source and attempt to authenticate using the internal cluster credentials. If the source is the same machine, or if the authentication is successful, then we assume the source machine is part of the same cluster and require the necessary privileges to read from source.

Comment by Andy Schwerin [ 21/Mar/13 ]

Can you describe a proposed solution?

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