[SERVER-13232] resetDbpath() ignores authentication Created: 27/May/13  Updated: 06/Dec/22  Resolved: 19/Nov/21

Status: Closed
Project: Core Server
Component/s: Security, Shell
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Ed Costello Assignee: Backlog - Server Tooling and Methods (STM) (Inactive)
Resolution: Won't Fix Votes: 0
Labels: move-stm
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mongo --version: MongoDB shell version: 2.4.3
mongod --version:
db version v2.4.3
Sun May 26 23:06:10.363 git version: fe1743177a5ea03e91e0052fb5e2cb2945f6d95f
uname -a:
Darwin monongahela 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan 6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64


Assigned Teams:
Server Tooling & Methods
Operating System: ALL
Participants:

 Description   

resetDbpath('/path') seems to be a mongo shell test function which is left enabled by default. It recursively removes the specified path (and {{mkdir()}}s a new directory with the same name).

Since it is run in the shell, it runs without regards to authentication. If the shell user has write access (or is root) to the specified path, all files are removed. Since it's run in the shell and is not a dbcommand, no message is logged to the server.

Note that startMongodEmpty is similarly destructive.

Reproduce:

mongo --eval 'resetDbpath("/data/db")'
mongo --eval 'startMongodEmpty("--dbpath", "/data/db", "--port" , "9999")'



 Comments   
Comment by Brooke Miller [ 19/Nov/21 ]

We've deprecated the mongo shell in favor of the new mongosh . Unfortunately, we aren't able to pursue improvements to the deprecated shell except in extreme cases, such as critical security fixes. Can you please start making use of mongosh and let us know if it works for you in this case?

Comment by Spencer Brody (Inactive) [ 28/May/13 ]

I agree with Andreas, though I also agree that we should be giving users less ways to shoot themselves in the foot.

The easiest solution may just be ripping out the functionality that's in the shell just for testing from the shell that we distribute to the public (which we've been talking about doing anyway).

In the meantime perhaps best-practice documentation that the shell should be run as an OS user without any write access to the file system?

Comment by Ed Costello [ 28/May/13 ]

Might also add a check that the specified path is the --dbpath and not "/" (for example).

Comment by Ed Costello [ 27/May/13 ]

I'm fine with someone deciding to move it to SERVER, I didn't want to leave it in the public project over the holiday weekend.

My reasoning opening it here: it's scriptable, it's non-obvious, it's available by default instead of with --setParameter enableSOMETHINGcommands.

Comment by Andreas Nilsson [ 27/May/13 ]

I am not sure I agree that this is a security issue even though the function should not exist unless it is required.

Any executable run with high enough permissions can erase the DB path. The shell is just another binary, albeit provided as part of the mongo installation.

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