[SERVER-8429] Tools cannot use SASL authentication mechanisms. Created: 31/Jan/13  Updated: 19/Mar/13  Resolved: 13/Feb/13

Status: Closed
Project: Core Server
Component/s: Security, Tools
Affects Version/s: 2.3.2
Fix Version/s: 2.4.0-rc1

Type: Bug Priority: Major - P3
Reporter: Andy Schwerin Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
is related to SERVER-6368 Make ToolTest run with auth when runn... Closed
Backwards Compatibility: Major Change
Operating System: ALL
Participants:

 Comments   
Comment by auto [ 13/Feb/13 ]

Author:

{u'date': u'2013-02-13T15:01:34Z', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-8429 Fix tests in jstests/tool.

The affected tests depended on a behavior of mongodump and mongorestore in 2.2
and prior, whereby the tools would attempt authentication via the users'
credentials against several databases, until one matched. This behavior is
risky, because it could leave the tool authenticating as a user with
insufficient privilege to do its task, and it is inconsistent with other tools.

The tool behavior in 2.4 is to authenticate against the target database if one
is supplied, or admin if none is supplied, unless the user overrides this
behavior by passing --authenticationDatabase=dbname to the tool.
Branch: master
https://github.com/mongodb/mongo/commit/00ac54a1d2bf8c30cef7c7d69e396da46c15c383

Comment by Andy Schwerin [ 13/Feb/13 ]

When running a tool against a server that requires authentication, behavior has changed. In earlier versions of the tools, some of the tools would attempt to authenticate using supplied credentials against the database that the tool was acting on, and if that failed, then try against the admin (and sometimes also local) database. In 2.4, the following determines what database is the target for authentication:

  1. If the user supplies --authenticationDatabase=D, the tool will authenticate against D.
  2. Otherwise, if the user supplied --db or --d to specify a target database for the tool's activity, the tool will authenticate against that database.
  3. Otherwise, the tool will authenticate against the "admin" database.
Comment by auto [ 13/Feb/13 ]

Author:

{u'date': u'2013-02-13T01:30:03Z', u'name': u'Tad Marshall', u'email': u'tad@10gen.com'}

Message: SERVER-8414/SERVER-8429 Fix SpiderMonkey compile
Branch: master
https://github.com/mongodb/mongo/commit/38db721f46d739a1356ea27b3ee5ad50669b8b15

Comment by Andy Schwerin [ 12/Feb/13 ]

Mongo shell and tools now support both a --authenticationMechanism argument, controlling the default authentication mechanism, and a --authenticationDatabase argument, controlling which database is used as the "userSource" for authentication. In the shell, this allows you to authenticate a user from one database while having the db object at startup refer to a different database.

E.g.,

mongo --authenticationDatabase=users -u andy -p password data

Comment by auto [ 12/Feb/13 ]

Author:

{u'date': u'2013-01-31T22:59:23Z', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-8414/SERVER-8429 Support SASL authentication in DBClient::auth() method, tools.

Introduces a new overload of the auth() method of DBClientWithCommands to the
C++ driver. The new overload takes a single BSONObj of authentication
parameters as input, and is analagous to the saslClientAuthenticate method.
This new method supports all SASL methods, if the client has GSASL support and
previously ran the mongo initializers, plus it supports MONGO_CR. It is the
preferred entry point for authentication in the C++ client, going forward.

The old ::auth() method remains and keeps its existing behavior.
Branch: master
https://github.com/mongodb/mongo/commit/1b2b144a8829296cfb1a8f78864eebfe752d9cb3

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