[SERVER-6782] All targeted queries will fail with db-level auth if primary shard is unavailable. Created: 16/Aug/12  Updated: 11/Jul/16  Resolved: 17/Sep/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: 2.0.7
Fix Version/s: 2.5.3

Type: Bug Priority: Critical - P2
Reporter: Ben Becker Assignee: Andy Schwerin
Resolution: Done Votes: 0
Labels: authentication, sharding
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Issue Links:
Depends
depends on SERVER-8580 User defined roles Closed
Related
Operating System: ALL
Participants:

 Description   

DB-level users are currently authorized on the primary shard server (as opposed to the config server with global/admin users). This has implications for targeted queries, as any targeted query with auth would require both the primary shard server and target shard server be available.

Further, when this case is encountered, the error messages can be quite confusing; either indicating that auth explicitly failed, or that a socket exception occurred (without mentioning the remote host):

leaf-linux:~/projects/mongo (v2.0) $ ./mongo --port 27037
MongoDB shell version: 2.0.8-rc0-pre-
connecting to: 127.0.0.1:27037/test
> use shtest
switched to db shtest
> db.auth('a', 'a')
0
> db.auth('a', 'a')
Thu Aug 16 12:21:26 uncaught exception: error { "$err" : "socket exception", "code" : 11002 }
> db.auth('a', 'a')
Thu Aug 16 12:21:38 uncaught exception: error { "$err" : "socket exception", "code" : 11002 }
> db.test.find({_id:ObjectId("502d4710eb0808c27833da2d")})  // this query would work without auth.
error: { "$err" : "unauthorized", "code" : 15845 }

Note this test was run after killing the primary shard server. Test environment is 2 shards with replication, where the targeted document lives on the non-primary shard.

We should probably note this caveat on the Shard Operation Types page until this is resolved.



 Comments   
Comment by Andy Schwerin [ 17/Sep/13 ]

This occured because in 2.4 and before, user documents are stored in the primary shard of their associated database. Starting with 2.5.2, they are stored in the admin database, on the config server, effectively eliminating this behavior.

Comment by Ben Becker [ 11/Mar/13 ]

schwerin, this is when connecting via mongos. I'm basing this on the fact that I use port 27037 for mongos instances in my local sharding test script.

Comment by Andy Schwerin [ 11/Mar/13 ]

benjamin.becker, to clarify, the case you are describing is one in which one directly contacts a shard server, rather than contacting a mongos, to run a query?

Comment by Andy Schwerin [ 07/Sep/12 ]

Sorry, my comment was about primary replicas, not primary shards. I remain unsure of what we want to do for 2.3/2.4, but my description of the reasoning from 2.2 no longer applies.

Comment by Andy Schwerin [ 07/Sep/12 ]

spencer and I discussed this when he was doing auth work on 2.2. I seem to recall that we made this choice explicitly, because the alternative was to trust that the secondary that you happened to connect to was sufficiently up-to-date to match your user credentials policy. Note that the primary needs only be available when you authenticate the connection, not subsequently.

The problem is that we don't know what the customer's authorization policy is. Are they OK with a guy who's just been fired having access to data on a slave-delayed replica? We don't really have a way to let them choose, so we made the conservative choice for them. This is a classic case of mechanism dictating policy instead of vice versa.

So, what should we do for 2.3/2.4?

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