[SERVER-27027] authorization failed (error 13) with Java 3.3 Created: 14/Nov/16 Updated: 13/Feb/17 Resolved: 13/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 3.2.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kamal Kalra | Assignee: | Kelsey Schubert |
| Resolution: | Incomplete | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
| Operating System: | ALL |
| Participants: |
| Description |
|
I'm trying to upgrade from MongoDB 3.0.0 to 3.2.10 on a Mac and continuously get an authentication error when trying to update a document (via a Java driver). Updating from the shell works fine. I've tried dropping the db and re-creating it in 3.2.1 and re-creating the user and role but regardless of the approach, Mongo still throws an exception. Reverting back to 3.0.0 works. |
| Comments |
| Comment by Kelsey Schubert [ 13/Feb/17 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi kamalkalra, Thank you for the additional information. Unfortunately, we have not been able to determine the root cause of this issue. Since a workaround has been identified, I am going to close this ticket. If we receive additional reports of this issue, we will continue to investigate. Thank you, | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 29/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Well the first thing I see wrong in your test case is the update statement. This failure happens on a $setOnInsert (see original stack trace). I can replicate the failure every time with the following code (on MongoDB 3.2.10 w/ Java driver 3.3.0):
| |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Kamal, Thanks for continuing to work with us. I tried again to re-create the scenario and still can't reproduce the issue. This time I created the four users in a fresh install of 3.0.12, then dropped in the 3.2.10 binary. This Java program, using the 3.3.0 driver, ran successfully against both server versions:
The users were created like this:
A couple of things you can do to get us more information: 1. Run mongod with verbose logging enabled (-vvv) and attach two sets of server log snippets, one with a successful run against 3.0.12 and one with a failing run against 3.2.10 Thanks, | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Ok. I'm happy to provide additional information (as long as I have the current DB setup). | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
As I indicated in an earlier comment I did test this and was unable to reproduce the error. So to get to the bottom of it we'd probably require more input from you to determine the difference in our respective environments. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Well, I can live with this solution. It's easier to manage. So from my end, I'm considering this issue closed. Regardless, I think you guys should add this scenario to your test cases. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Kamal, Glad to hear that you arrived at a solution, though not the root cause of the original issue. Would you like to keep investigating or should we close this? | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Creating the user in the admin DB worked! But the approach to create the user was exactly the same as the one in the other DBs so I'm not sure why it works in one DB and not another. Regardless, it's a solution for now... Thanks. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Ok, that makes sense. The users (for "User" and "NubiDo") have been in place since the early MongoDB 2.X releases. I'll try migrating them to the admin DB. The most recent stack trace is from the clean install of MongoDB 3.2.10. The earlier stack trace and log files were from the upgrade (from 3.0 to 3.2.10). Here's the output from the shell commands:
| |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 28/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Kamal, Since MongoDB 2.6 it has been possible to create a single user with rights to multiple databases. There is no need any more to create more than one user for a single application. For this use case, you could create a single "NubiDo" user in the "admin" database with the "readWrite" role on the "User, "NubiDo", "User2", and NubiDo2" databases, or particular collections in those databases. Regardless, you're right that having multiple users is still supported and should work. Unfortunately, I'm not able to reproduce the authorization error with the 3.3.0 driver, either with a single user or with multiple users. One thing I noticed is that the exception from the stack trace does not match the mongod.log file output. In the exception, the error message from the server is:
while in the log file the message is:
Notice that both the database and collection names are different. Also, in the code sample four credentials are added for four different databases, while in the log file there are three successful authentications, but none for the "NubiDo2" database. Please double check the log files and make sure that the provided logs are for the failed execution. Also, please investigate why only three Also, in the shell please run the command
in each of the four databases and attach the responses for all of them. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 27/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
I'm a bit confused. I was under the impression that a user had to be created for a particular database. Where would I create a user that can span a specific set of databases? I have root users in the admin DB but those are specifically for administration purposes and not used by the app. The other users are specifically for the app and the appropriate DBs. But why would having multiple users make a difference? Either case, it should work (and in fact does in the mongo shell). This seems to be a driver issue, not a multiple user issue, correct? Also, when executing the command in the shell, I use db.auth(user, password) to authenticate or pass in -u and -p options to the command line when entering the shell, both of which work correctly. I don't recall if the logs I attached has that particular use case but I've tested this many times in the shell. I'll get you a new log file with that specific use case. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 27/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Kamal, No, we're not able to replicate this yet. One difference between your configuration and the ones that we regularly test with is the fact that you've defined multiple users, all with the same user name, in four different databases. Can you explain your rationale for that? Can you simplify your test case to a single user that has all necessary permissions? With role-based access control, that's certainly possible to do. For example, you can create a single user with the built-in readWriteAnyDatabase role. Also, as requested earlier please provide the series of mongo shell commands that are successfully executed (including the steps to authenticate the user), as well as the mongod logs for that successful execution (or is that 'conn2' in the already-attached log file?). | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 27/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Jeff,
| |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Jeffrey Yemin [ 27/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Kamal, please share a snippet of Java code that shows how you specify the username/password for your MongoClient instance (of course, elide the real password), e.g.
or
I'm curious what you're doing given that the mongod logs show three different authentications on three different databases, all successful, before the failed authorization to update a collection in the User2 database:
| |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 27/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
One more update. I'm able to get this working with the 3.0.3 Java driver and MongodDB 3.2.10. According to the MongoDB documentation, this driver shouldn't even be compatible with MongoDB 3.2.X but it seems to work. Switching back to a more recent driver immediately causes the authorization exception. But since the 3.0.3 driver isn't listed to be compatible, I'm not sure whether it should be trusted in a production environment. Please advise. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 26/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Is there any update on this? Are you guys able to replicate this behavior? I've even tried a clean install of 3.2.10 and it exhibits the same problem where the query works correctly via the shell, but not the Java driver. | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 15/Dec/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Thomas,
| |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kelsey Schubert [ 28/Nov/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi kamalkalra, The logs indicate that there was an authorization error. So we can better understand what is going on would you please provide the series of mongo shell commands that are successfully executed (including the steps to authenticate the user)? And describe where the failure occurs using the JAVA driver? Would you also please clarify how you upgraded to MongoDB 3.2? (e.g. did you perform an initial sync?) Thank you, | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kamal Kalra [ 14/Nov/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi Thomas, Thanks, | |||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Kelsey Schubert [ 14/Nov/16 ] | |||||||||||||||||||||||||||||||||||||||||||||||
|
Hi kamalkalra, Thank you for the report. I'd like to confirm a few details with you. My understanding is that you upgraded only the mongod binaries from 3.0.0 to 3.2.10, and kept the Java Driver at version 3.2.1. Is this correct? Additionally, would you please upload the logs of the mongod that you are unable to auth against? Thank you for your help, |