[SERVER-7155] Problem with authentication of connections used for mapReduce when writing to an output collection Created: 25/Sep/12  Updated: 10/Dec/14  Resolved: 25/Apr/13

Status: Closed
Project: Core Server
Component/s: MapReduce
Affects Version/s: 2.2.0
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Jeffrey Yemin Assignee: Unassigned
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to JAVA-651 MapReduce output to a temp db collect... Closed
is related to CSHARP-581 MapReduce output to a collection in a... Closed
Participants:

 Description   

In 2.2.0, the behavior of mapReduce changed with respect to authentication. In 2.0.x, if the output collection is in a different database than the input collection (using "db" field in "out" document), the server would write to that collection even if the connection was not authenticated to that db. In 2.2 that changes, and the server returns an error:

{ "serverUsed" : "localhost/127.0.0.1:30000" , "errmsg" : "exception: unauthorized db:mrtesttarget ns:mrtesttarget.tmp.mr.imr1_0_inc lock type:1 client:127.0.0.1" , "code" : 10057 , "ok" : 0.0}

The problem is that many drivers lazily authenticate connections based on the database that a command is being run against, and do not consider things like different output directories for mapReduce (or for future support in aggregation framework). So even if an application authenticates against the other database, the connection that ends of being used for the mapReduce command may or not have been authenticated to that other database, depending on if that connection happened to already have been used to run some operation against that other database already.

This could be fixed solely in the drivers, but it would involve either:

  • authenticating every connection against every database
  • pushing knowledge of commands down to a lower level of the driver
  • parsing the error message returned by the server and retrying the command

A possible way to handle this more gracefully is to have the server respond with a challenge document that identifies additional databases that need to be authenticated against before the command can be executed.



 Comments   
Comment by Andy Schwerin [ 25/Apr/13 ]

It turns out that the drivers basically need to authenticate every connection with every registered credential, anyways. In 2.4 and beyond, one credential can grant access to many databases, further mitigating the impact of this behavior.

Comment by Scott Hernandez (Inactive) [ 26/Sep/12 ]

Dan, there are many places/commands: clone/copyDatabase, renameCollection and I'm sure others if I look into it.

It would be best if the server can communicate which dbs the client must authenticate to in the error message.

Comment by Daniel Pasette (Inactive) [ 25/Sep/12 ]

It would be easy enough to handle this particular case (and going forward, aggregation's $out) by having the driver deal with these special cases itself. The error document approach is more generic, but I can't think more places we would need this other than those two places and would require both driver and server changes to implement.

Comment by Andy Schwerin [ 25/Sep/12 ]

I like the structured error document approach.

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