[SERVER-4122] Validate database and collection names on the server before creating them Created: 21/Oct/11  Updated: 15/Aug/12  Resolved: 21/Feb/12

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chris Westin Assignee: Randolph Tan
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-4229 mongodump creates a database named * ... Closed
Duplicate
duplicates SERVER-4584 mongod crashes when trying to create ... Closed
is duplicated by SERVER-5248 CLONE - Mongodump error: "error: boos... Closed
Related
is related to SERVER-4302 user shouldn't be able to create coll... Closed
is related to SERVER-5002 Change prohibited character sets in d... Closed
Operating System: ALL
Participants:

 Description   

This is a call to prevent the creation of databases or collections with illegal names.

During a recent training, some of the trainees ran into a problem when we were doing backups using mongodump. mongodump stopped, giving an error message because it couldn't dump a database named "*". "show dbs" in the shell confirmed that there was indeed a database named "*". (But attempting to use it failed because that led to a "..." continuation prompt.) But only a few people were affected, so this doesn't appear to be systemic. It seems likely that this was created accidentally as a result of some earlier mistyped command, possibly an attempt to use a wild card incorrectly.

In some contexts, this name worked, and in others it didn't, leading me to believe we're not validating these on the server, but are instead relying on client parsers to keep them out, but apparently not always successfully.



 Comments   
Comment by Randolph Tan [ 21/Feb/12 ]

The fix on SERVER-4584 makes it impossible to create a database name with * (and other characters illegal in Windows filesystem). The server will fail to start if there is an existing db that has a "*" database name (by design?). However, mongodump can still dump the files with the dbpath specified and -d * (needs to be escaped in bash shell since the shell will pass all files in the cwd as arguments to the mongodump program).

A related ticket (SERVER-5002) was also created a few days ago which is currently in the planning bucket.

Comment by Ben Becker [ 27/Jan/12 ]

I'm able to reproduce this from master on OSX by running 'mongodump -d *'. It seems to create a database named after the first file (or folder) in my cwd (in this case, the 'dump' folder):

fire:test ben$ ls
dump
fire:test ben$ ../mongo/mongodump --port 27017 -d *
connected to: 127.0.0.1:27017
Fri Jan 27 00:44:49 DATABASE: dump	 to 	dump/dump
fire:test ben$ ls -al dump/
total 0
drwxr-xr-x  2 ben  staff   68 Jan 27 00:43 *
drwxr-xr-x  4 ben  staff  136 Jan 27 00:43 .
drwxr-xr-x  3 ben  staff  102 Jan 27 00:43 ..
drwxr-xr-x  2 ben  staff   68 Jan 27 00:43 dump
fire:test ben$ ../mongo/mongo --port 27017 
MongoDB shell version: 2.1.0-pre-
connecting to: 127.0.0.1:27017/test
sh1:PRIMARY> show dbs
dump	(empty)
...

mongodump is doing something with the -d argument that creates a db named after the first file in cwd, and when I run the command again without the -d argument, it creates a folder named '*' and 'dump'. When we saw this on Windows (primarily with cygwin), mongodump would fail while trying to create the directory named '*'. Will dig deeper as time permits.

Comment by Chris Westin [ 19/Jan/12 ]

I'm now seeing this again on 2.0.2. But it looks more like SERVER-4229, where we can't make the "*" database go away. This is interfering with mongodump. When I originally reported this in this ticket, we were able to make the "*" database go away using db.getSiblingDB("*").dropDatabase(). However, that workaround is no longer working, so I don't think 4229 is actually a duplicate of this. Again, originally [1.8-2.0), only some trainees got this, and we were able to get rid of it. Now, in 2.0.2, everyone gets it, and we can't get rid of "*", so it looks like a different problem – something has changed.

Comment by Doug Donohoe [ 29/Nov/11 ]

Can somebody take a look at SERVER-4229? Thanks!

Comment by Tony Hannan [ 04/Nov/11 ]

I chose to keep allowing special chars such as * in db name for backwards compatibility. So I fixed mongodump and the shell to work with them.

Comment by auto [ 04/Nov/11 ]

Author:

{u'login': u'TonyGen', u'name': u'Tony Hannan', u'email': u'tony@10gen.com'}

Message: SERVER-4122: "" is a valid dbname. make mongodump use "" instead of "" to represent all dbs – "" is not a valid dbname. Also make shell "use" command accept "*" or any other special char as dbname
Branch: master
https://github.com/mongodb/mongo/commit/98314e257e38a1621120bb96e284cf9c8c760ecc

Comment by Chris Westin [ 03/Nov/11 ]

If you want to go about it that way, it's not just the shell. The original problem was spotted because mongodump died when it got to a db named "*".

It seems odd to disallow the chars above instead of simply requiring the db (and collection) names to be the usual programming language variable form: [a-zA-Z_][a-zA-Z0-9_]* That's pretty safe for anything. In C/C++, that's pretty easy to detect by using macros from ctype.h, usually isalpha() and isalnum().

Comment by Tony Hannan [ 03/Nov/11 ]

Currently, '/', '\', '.', ' ', and '"' are disallowed in db names (see Database::validDBName). Do we want to add '*' to that list, or do we want to make the shell work when the user types use *. Currently db.getSiblingDB("*").foo.find() works in the shell.

Comment by Chris Westin [ 03/Nov/11 ]

Jira is making everything bold between two asterisks up there. The db name wasn't empty, it was an asterisk.

Comment by Chris Westin [ 03/Nov/11 ]

I don't know. But I got one named "*" (a single asterisk). It looks like jira markup might be turning that into something else.

Comment by Tony Hannan [ 03/Nov/11 ]

Do you know how a db with empty name was created? I get error 13075 "db name can't be empty" when I try to insert into a db named "".

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