[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:
Depends
depends on SERVER-2079 Authenticated Connections do not get ... Closed
is depended on by SERVER-3841 Profiling in admin DB can stick entri... Closed
Related
related to SERVER-2329 Dropped database doesn't disappear du... Closed
related to SERVER-13212 ListDatabases implementation can caus... Closed
related to SERVER-11051 listDatabases command reports existen... Closed
is related to SERVER-10783 MongoDB displays databases even after... Closed
Operating System: ALL
Participants:
Case:

 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] assertion 10057 unauthorized db:clobby-staging lock type:-1 client:10.104.83.235 ns:clobby-staging.rooms query:

{ slug: "groupchat" }

Tue Nov 9 04:55:06 [conn2] ntoskip:0 ntoreturn:-1
Tue Nov 9 04:55:06 [conn2] query clobby-staging.rooms ntoreturn:1 exception 0ms

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
Python 2.7.2+ (default, Oct 4 2011, 20:06:09)
[GCC 4.6.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pymongo
>>> print pymongo.version
2.5
>>> db = pymongo.Connection('ds059557-a.mongolab.com:59557', 59557).zAngelaTest
>>> db.authenticate("junk_username_wont_work", "same_thing_for_password")

rs-ds059557:PRIMARY> db.version()
2.4.3
rs-ds059557:PRIMARY> show dbs
...
zAngelaTest (empty)
...

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?

% mongo localhost/admin -u *** -p ***                                  
MongoDB shell version: 2.4.3
connecting to: localhost/admin
> db.version()
2.4.3
> show dbs
admin	0.03125GB
local	0.28125GB
> exit
bye
 
% mongo localhost:27997/bowtiesarecool
MongoDB shell version: 2.4.3
connecting to: localhost/bowtiesarecool
> show dbs
Wed Apr 24 14:46:40.140 JavaScript execution failed: listDatabases failed:{ "ok" : 0, "errmsg" : "unauthorized" } at src/mongo/shell/mongo.js:L46
> exit
bye
 
% mongo localhost/admin -u *** -p ***                                  
MongoDB shell version: 2.4.3
connecting to: localhost/admin
> show dbs
admin	0.03125GB
local	0.28125GB
> exit
bye
 
% mongo localhost/bowtiesarecool
MongoDB shell version: 2.4.3
connecting to: localhost/bowtiesarecool
> db.setProfilingLevel(2)
{ "ok" : 0, "errmsg" : "unauthorized" }
> exit
bye
 
% mongo localhost/admin -u *** -p ***                                  
MongoDB shell version: 2.4.3
connecting to: localhost/admin
> show dbs
admin	0.03125GB
local	0.28125GB

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.

% mongo localhost/admin -u *** -p ***
MongoDB shell version: 1.8.2
connecting to: localhost/admin
> show dbs
admin	5GB
local	5GB
> exit
bye
 
% mongo localhost/bowtiesarecool                              
MongoDB shell version: 1.8.2
connecting to: localhost/bowtiesarecool
> show dbs
Tue Sep 13 17:01:01 uncaught exception: listDatabases failed:{
	"assertion" : "unauthorized db:admin lock type:-1 client:127.0.0.1",
	"assertionCode" : 10057,
	"errmsg" : "db assertion failure",
	"ok" : 0
}
> exit
bye
 
% mongo localhost/admin -u *** -p ***
MongoDB shell version: 1.8.2
connecting to: localhost/admin
> show dbs
admin	5GB
local	5GB
> exit
bye
 
% mongo localhost/bowtiesarecool                              
MongoDB shell version: 1.8.2
connecting to: localhost/bowtiesarecool
> db.setProfilingLevel(2)
{
	"assertion" : "unauthorized db:bowtiesarecool lock type:1 client:127.0.0.1",
	"assertionCode" : 10057,
	"errmsg" : "db assertion failure",
	"ok" : 0
}
> exit
bye
 
% mongo localhost/admin -u *** -p ***
MongoDB shell version: 1.8.2
connecting to: localhost/admin
> show dbs
admin	5GB
bowtiesarecool	(empty)
local	5GB
> exit
bye

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
MongoDB shell version: 1.9.0-pre-
connecting to: 192.168.1.29/test
> db
test
> db.foo.find()
error: {
"$err" : "unauthorized db:test lock type:-1 client:192.168.1.29",
"code" : 10057
}
> use aaa
switched to db aaa
> db.foo.find()
error: {
"$err" : "unauthorized db:aaa lock type:-1 client:192.168.1.29",
"code" : 10057
}
> db
aaa
> db.foo.insert({})
unauthorized
> use test
switched to db test
> db.auth("joe","joe")
1
> db.foo.find()

{ "_id" : ObjectId("4db58a7784dd321dc4d50cea") }

...
> use aaa
switched to db aaa
> db.foo.find()
error: {
"$err" : "unauthorized db:aaa lock type:-1 client:192.168.1.29",
"code" : 10057
}
> db.foo.insert({})
unauthorized

Comment by Justin Smestad [ 01/May/11 ]

Is there any movement on this?

Generated at Thu Feb 08 02:58:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.