[SERVER-10926] NamespaceString inconsistent on allowing '$' in database name Created: 26/Sep/13  Updated: 06/Dec/22  Resolved: 02/Apr/20

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

Type: Bug Priority: Minor - P4
Reporter: J Rassi Assignee: Backlog - Storage Execution Team
Resolution: Done Votes: 0
Labels: query-44-grooming
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-42009 Forbid creation of collections with n... Closed
Related
is related to SERVER-22577 mmapv1 should not allow creation of d... Closed
Assigned Teams:
Storage Execution
Operating System: ALL
Sprint: Execution Team 2019-10-07
Participants:

 Description   

"$test" passes NamespaceString::validDBName(), but "$test.foo" doesn't pass NamespaceString::normal().

I believe the bug is in NamespaceString::normal(), and the correct behavior is that "$test.foo" should pass validation.



 Comments   
Comment by Eric Milkie [ 04/Nov/19 ]

We may want to consider reverting the ticket that unlocked the ability to create databases with $ in the name, just in 4.3.

Comment by Eric Milkie [ 16/Aug/19 ]

I think we may have fixed or changed the behavior with this recently with our code changes to NSS normal(); we will check.

Comment by David Storch [ 16/Aug/19 ]

I believe that the Execution Team would be in the best position to triage an issue around validation of database names. I'm moving it to their backlog and flagging for triage.

Comment by Robert Guo (Inactive) [ 28/Mar/16 ]

(I removed my two previous comments which no-longer apply to this ticket)

After discussing with kamran.khan and geert.bosch, I'm removing this ticket from my queue and setting the fix version to "Planning Bucket A" (and should be moved to 3.5 required/desired).

The problem is that there are a few dozen uses of NamespaceString::valid() scattered throughout the codebase, and modifying its behavior could subtly break some behavior. This is especially risky for our auth code.

We also don't want to make '$' a valid db name character in NamespaceString::normal, which would allow users to create and use databases containing "$". While there're no filesystem or OS issues with having a "$" in the dbname, our drivers will all need to be updated to support this "feature", which is likely a lot more work and a potential cause for instability.

The preferred solution is to fix SERVER-22577 in 3.3 so that no users will have any databases containing "$" in 3.4 (except $external); then, in the 3.5 cycle, we can make "$" fail NamespaceString::validDBName() and manually go through all places that use validDBName to add checks for "$external" explicitly wherever $external is needed. It will be much easier to reason about the logic once we know there won't be any databases containing "$".

Comment by Kamran K. [ 04/Jan/16 ]

The issue mentioned by jonathan.abrahams seems to have been introduced between 2.6 and 3.0. I think it's a separate bug from the one in the initial description.

Comment by Jonathan Abrahams [ 30/Dec/15 ]

This permits the users to create a DB with a $ in it, for mmapv1, but not wiredTiger. Try this code against both storage engines (in 3.2.0):

use $foo
db.bar.insert({})
show dbs

Comment by J Rassi [ 27/Sep/13 ]

The user-visible side effects of this are that some operations/commands against these databases will succeed, and some won't:

> use $test
switched to db $test
> db.dropDatabase() // works
{ "dropped" : "$test", "ok" : 1 }
> db.foo.insert({}) // does not work
cannot insert into reserved $ collection

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