Major - P3 ISSUE SUMMARY
For v2.4 style users, MongoDB checks for surrogate users on the database being accessed. If no such user is present, MongoDB does not mark the database as "probed", and keeps checking for a surrogate document every time the user executes an operation on the same database. This can cause serious slowdowns in a system using a 2.6 mongos with v2.4 style users.
USER IMPACT
Environments with v2.4 style users can experience significant performance impact due to the repeated queries on the system.users collection. The impact is more pronounced on sharded configurations because of network round trips.
WORKAROUNDS
A workaround is to add a surrogate user document with no roles to the database for the user in question. For example, if user Bob is defined on the admin database, and this user is used to access the foo database, run the following on foo:
> use foo
> db.addUser({user:'Bob', userSource:'admin', roles:[]});
When probing for user documents on that database, this will return a document, and therefore mark the database as "probed" for this particular user.
AFFECTED VERSIONS
Versions 2.6.0 and 2.6.1 were affected by this issue.
FIX VERSION
The fix is included in the 2.6.2 production release.
RESOLUTION DETAILS
The database is marked as probed in the authorization manager, even if no surrogate user has been found.
Original description
In v2.4 a user defined on db A can be given privileges on db B by adding a "surrogate" user document on db B. To support this functionality in 2.6, whenever we do an authorization check for a v2.4 style user, we check if there is a surrogate user doc for that user on the database being accessed. We keep track of which databases we've already checked for surrogate documents for each user, in that user's list of "probed" databases. The problem is that if there is not a surrogate doc for a user on a given database, we neglect to mark that database as probed, which means that the next time that user does an operation on the same database it will try to check for a surrogate doc again, every single time. This can cause serious slowdowns in a system using a 2.6 mongos with v2.4 style users.