[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: |
|
||||||||||||
| 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:
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:
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. |