[SERVER-21486] successful authentication does not give full privilege with 3.0 mongos and 3.2 mongod Created: 16/Nov/15 Updated: 25/Jan/17 Resolved: 20/Nov/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security, Sharding |
| Affects Version/s: | 3.2.0-rc2 |
| Fix Version/s: | 3.2.0-rc4 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Spencer Brody (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Steps To Reproduce: | run jstests/sharding/authmr.js with everything in 3.2 expect for mongos, which is in 3.0 |
||||||||||||||||||||
| Sprint: | Sharding C (11/20/15), Sharding D (12/11/15) | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
It appears that even if a user authenticates successfully as an admin user, it does not have the full privilege. This appears be the culprit since ActionSet::parseActionSetFromStringVector breaks out immediately when it sees an unrecognized action:
|
| Comments |
| Comment by Githook User [ 20/Nov/15 ] | |||||
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: | |||||
| Comment by Githook User [ 20/Nov/15 ] | |||||
|
Author: {u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}Message: | |||||
| Comment by Andy Schwerin [ 18/Nov/15 ] | |||||
|
I'm leaning towards option 2, right now. I know it's a little hacky, but I We could use either the use of OP_COMMAND or a new argument to getUserInfo We should also fix 3.2 so we won't need a hack in the future. That could On Tue, Nov 17, 2015, 5:30 PM Andreas Nilsson (JIRA) <jira@mongodb.org> | |||||
| Comment by Spencer Jackson [ 17/Nov/15 ] | |||||
|
Though I couldn't get the test working for me, I can reproduce this issue by directly directly mongods and a mongos. It looks like mongo::V2UserDocumentParser::initializeUserPrivilegesFromUserDocument skips entire privilege documents if they contain a single permission it doesn't recognize. If you create a user with dbAdminAnyDatabase, it will have a privilege which looks something like:
I'll attach the pretty printed BSON that mongo::V2UserDocumentParser::initializeUserPrivilegesFromUserDocument was processing. | |||||
| Comment by Andreas Nilsson [ 17/Nov/15 ] | |||||
|
I think mongos should just ignore new action/privilege types but not fail. It doesn't really make sense to act on a 3.2 privilege in a 3.0 node anyways since the privilege isn't connected to an actual command in the older system. | |||||
| Comment by Spencer Brody (Inactive) [ 17/Nov/15 ] | |||||
|
Oh shoot, this is because we changed the upgrade order to mongods before mongoses, but mongos loads the privilege set for users at authentication time by running usersInfo against the config server. We may need to make mongos just ignore privileges it doesn't recognize rather than erroring, then you just won't be able to build a user capable of a feature with a newly-added privilege until you've fully upgraded all binaries in your system, which isn't super great, but also isn't terrible. The real risk isn't for new features with have a corresponding new ActionType, as those likely won't work until fully upgraded anyway, but for if we try to make the privilege checks for an existing feature/command more fine grained by introducing a new action type for performing a specific subset of invocation forms for a given command. Since any such change would need to have backwards-compatible privilege checks anyway I think this may be fine? andreas.nilsson, what do you think? |