[SERVER-31071] copyDatabase() command doesn't support an auth DB parameter Created: 12/Sep/17 Updated: 27/Oct/23 Resolved: 10/Aug/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Richard Pavlicek | Assignee: | Maria van Keulen |
| Resolution: | Gone away | Votes: | 1 |
| Labels: | platforms_security | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Storage NYC 2018-08-13 | ||||||||
| Participants: | |||||||||
| Description |
|
db.copyDatabase has parameters: fromhost, username and password. However, the user is only authenticated against the fromdb. We use many databases but store our user authentication in the admin database. There should be an optional 'authdb' parameter which allows the user to be authenticated against that instead. It seems inconsistent, since we can connect to a mongo server using any database as the authdb, and then access other databases. See |
| Comments |
| Comment by Maria van Keulen [ 10/Aug/18 ] |
|
Closing since the copyDB command was removed as of |
| Comment by Gregory McKeon (Inactive) [ 23/Jul/18 ] |
|
Sending to storage to close when they remove copydb. |
| Comment by Sara Golemon [ 15/Sep/17 ] |
|
Yeah, none of my earlier suggestions are particularly scalable for non one-off issues. As to fixing copyDatabase() I have bad news and good news. Bad news: We're already in feature freeze for 3.6, so it's a little too late to get this change in (it's not as simple as it sounds at first glance). Good news: We already have work scheduled for the next release which, as a side-effect, will make this problem disappear. In fact, your approach of keeping all users in the admin DB fits in perfectly with this update. So if your client-side read/writes are working for now, albeit imperfectly, I'd ask for your patience and to keep an eye on next year's release. |
| Comment by Richard Pavlicek [ 14/Sep/17 ] |
|
Thanks for responding! For us this is not a one-off problem, as we create many database dynamically, and then occasionally have to copy them across environments. We thought of a solution like yours (have a higher privilege user create a user on the fromDB dynamically, and then delete it after the copy is done), but this creates security headaches for us which we'd rather avoid. Backup/restore is also not a good option, since this is meant to be done by a dynamic PHP application – not a MongoDB admin. For now, the best solution (for us) is to read/write the data, until this function is enhanced. Thanks! |
| Comment by Sara Golemon [ 13/Sep/17 ] |
|
Hello! Yes... That certainly seems like an oversight, and I'm sorry for the frustration this is likely causing. Allow me to have a few conversations here to figure out the best way to address this moving forward. In the mean time, I wanted to check in and see if you were able to come up with a workaround. If this is a one-off problem you've only just encountered then creating a temporary user in the fromdb would probably be the most expedient. A backup/restore might also work for a more generalized case. |