[SERVER-2080] Connecting to an authenticated server creates the database namespace regardless of success or failure. Created: 09/Nov/10 Updated: 21/Sep/17 Resolved: 02/Mar/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 1.6.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Justin Smestad | Assignee: | DO NOT USE - Backlog - Platform Team |
| Resolution: | Done | Votes: | 8 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
ubuntu 10.04 |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||
| Description |
|
There is a bug when running in an authenticated environment and a connection tries to access a database that does not exist on the system. What mongo is doing is creating the database trying to authenticate the given connection (see logs below). This now means when I go into mongo shell and type `show dbs;` I will see the database namespace created (but it is empty). This makes it very difficult to use `show dbs` to see what databases a given mongo daemon has associated with it because many of them could be empty. In addition, this becomes a larger issue when running a replication scenario which has a single slave and multiple masters (which works flawlessly as long as database names do not conflict). The logs of this happening: Tue Nov 9 04:55:06 [conn2] Accessing: clobby-staging for the first time Tue Nov 9 04:55:06 [conn2] ntoskip:0 ntoreturn:-1 This issue is an authentication issue that is similar to http://jira.mongodb.org/browse/SERVER-2079 but different enough use case that I felt it needed its own ticket. |
| Comments |
| Comment by Eric Milkie [ 02/Mar/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I tested this behavior in 3.4 and I could no longer create databases with the authenticate command. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Randolph Tan [ 17/May/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Attempting to query with the proper privileges no longer creates phantom databases in 2.4 (in memory only, and does not persist after a restart). However, trying to run the authenticate command on a non-existing database still creates phantom databases. Note that write commands like drop and repair doesn't create phantom databases. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Angela Shulman [ 25/Apr/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I just ran a test using pymongo 2.5 against version 2.4.3 and was able to reproduce the problem. [04/25/13 4:15] $ python rs-ds059557:PRIMARY> db.version() local 2.0302734375GB | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jared D. Cottrell [ 24/Apr/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Just re-ran my earlier test using 2.4.3 for OS X (64-bit). Looks like the unauthorized setProfilingLevel() call no longer creates an empty database. Was this intentionally fixed or was it accidental? More importantly, is there a regression test to make sure it's not accidentally broken again?
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Olga Smirnova [ 15/Apr/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I still have this in version 2.2.1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jared D. Cottrell [ 14/Sep/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I'm seeing something similar in 1.8.2 (both shell and DB are 64-bit Mac v.1.8.2). Note that in this example no actual DB files were created for the bogus DB. But it does show up in the response to "show dbs" from the shell.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Dwight Merriman [ 02/May/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
does this still happen? i just tried and could not reproduce. after the sequence below, on a server running --auth, there are no aaa.* data files. — $mongo 192.168.1.29 ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Justin Smestad [ 01/May/11 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Is there any movement on this? |