[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: File userdoc.json    
Issue Links:
Related
related to SERVER-21659 bypassDocumentValidation authenticati... Closed
is related to SERVER-21535 mongos should ignore actions it doesn... Closed
is related to SERVER-21561 Remove privilege redaction added for ... Closed
is related to SERVER-21487 Add new suite for running 3.2 SCCC cl... Closed
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:

2015-11-16T15:57:49.199-0500 W ACCESS   [conn1] Could not parse privilege element in user document for admin@admin: Unrecognized action privilege string: bypassDocumentValidation
2015-11-16T15:57:49.218-0500 I ACCESS   [conn1] Successfully authenticated as principal admin on admin



 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: SERVER-21486 Fix sasl_authentication_session_test
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/80b0325ab1b5a01fb7ce53f0ac1b6bd0c45ae848

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: SERVER-21486 Redact bypassDocumentValidation from user privilege set when being talked to by a 3.0 mongos
Branch: master
https://github.com/mongodb/mongo/commit/874fc812768718f015e81d6ce7bd2dab9ce14128

Comment by Andy Schwerin [ 18/Nov/15 ]

I'm leaning towards option 2, right now. I know it's a little hacky, but I
would like to avoid forcing a mongos upgrade to 3.0.8 to enable a further
upgrade to 3.2.

We could use either the use of OP_COMMAND or a new argument to getUserInfo
to drive behavior. I have a modest preference for detecting with
OP_COMMAND, but I haven't really considered the consequences.

We should also fix 3.2 so we won't need a hack in the future. That could
hit 3.2.1, though.

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:

    { "resource" : { "db" : "",
        "collection" : "" },
      "actions" : [ 
        "bypassDocumentValidation", 
         ...

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?

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