[SERVER-29050] Create upgrade/downgrade mechanism for adding and removing ActionTypes Created: 03/May/17  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Internal Code, Security
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Spencer Jackson Assignee: Backlog - Security Team
Resolution: Unresolved Votes: 1
Labels: platforms-re-triaged, upgrade
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Gantt Dependency
has to be done before SERVER-16425 Remove action type for emptycapped co... Backlog
Related
related to SERVER-43243 Reintroduce unused repairDatabase Act... Closed
is related to SERVER-21535 mongos should ignore actions it doesn... Closed
Assigned Teams:
Server Security
Participants:

 Description   

'ActionTypes' are actions which may be performed on resources in the database. Before a user may perform an operation, the server will validate that it possesses a privilege which grants all relevant ActionTypes on every resource which might be affected by the operation. Privileges may be granted to users by assigning them to one of the 'builtin' roles, or by creating a custom role with the privilege and assigning them membership.

When MongoDB introduces new commands, and new ways to interact with resources, it may introduce new ActionTypes. They may be used immediately after upgrading any node which takes writes and stores user data, and adding them to custom roles. When they are added to custom roles, a role document on disk will contain the name of the new ActionType.

To prevent themselves from loading corrupted data, nodes will not instantiate privileges containing unrecognized ActionTypes. Note that privileges containing an unrecognized ActionType, and one or more recognized ActionType will not be loaded. Nodes may observe unrecognized ActionTypes when loading their authorization information out of system collections during startup, or during replication. This could result in users and roles not obtaining granted privileges when running in a mixed mode environment, or when downgrading after creating custom roles.

Nodes could ignore ActionTypes they didn't recognize, but this would imply that illegal/unknown ActionTypes could persist indefinitely in authorization data. It also implies that ActionTypes may never be retired.

Alternatively, we could prevent new ActionTypes from being added to custom roles until after a feature compatibility upgrade, and not allow downgrading until all new ActionTypes have been removed from custom roles.



 Comments   
Comment by Spencer Jackson [ 04/May/17 ]

SERVER-21535 fixed the case where a config server sent a mongos privileges with ActionTypes the mongos didn't understand. It did this by changing parseActionSetFromStringVector and parsedPrivilegeToPrivilege to return a list of all unrecognized ActionTypes it encountered. V2UserDocumentParser::initializeUserPrivilegesFromUserDocument, which translates processed user description documents containing all privileges granted by all of a user's roles into objects for use by the AuthorizationManager, was changed to warn and not fail if it detected unrecognized ActionTypes.

It didn't change the behavior of parseAndValidatePrivilegeArray, which will explicitly return a non-OK Status when it detects unrecognized ActonTypes. This function is used in the user management commands and, by failing, prevents them from being used to create custom roles with unrecognized ActionTypes. But it gets used elsewhere, and the RoleGraph uses it to parse roles.

To demonstrate, modify action_types.txt to include a new ActionType called "foo".
Start the server without auth, and run:

MongoDB Enterprise > db.createRole({role: "foo", roles: [], privileges: [{resource: {db: "", collection: ""}, actions: ["foo", "find"]}]})
{
        "role" : "foo",
        "roles" : [ ],
        "privileges" : [
                {
                        "resource" : {
                                "db" : "",
                                "collection" : ""
                        },
                        "actions" : [
                                "foo",
                                "find"
                        ]
                }
        ]
}
MongoDB Enterprise > db.createUser({user: "sajack", pwd: "sajack", roles: ["foo"]})
Successfully added user: { "user" : "sajack", "roles" : [ "foo" ] }
MongoDB Enterprise >

Remove the new ActionType, recompile, and restart the server with auth. Notice that the following warning is printed to the log:

2017-05-04T13:47:46.778-0400 W ACCESS   [initandlisten] Skipping invalid admin.system.roles document while calculating privileges for user-d
efined roles:  FailedToParse: Unrecognized action privilege strings: foo; document { _id: "admin.foo", role: "foo", db: "admin", privileges:
 [ { resource: { db: "", collection: "" }, actions: [ "find", "foo" ] } ], roles: [] }

Now, login using the user, and check your privileges.

MongoDB Enterprise > db.auth("sajack", "sajack")
1
MongoDB Enterprise > db.runCommand({connectionStatus: 1, showPrivileges: 1})
{
        "authInfo" : {
                "authenticatedUsers" : [
                        {
                                "user" : "sajack",
                                "db" : "admin"
                        }
                ],
                "authenticatedUserRoles" : [
                        {
                                "role" : "foo",
                                "db" : "admin"
                        }
                ],
                "authenticatedUserPrivileges" : [ ]
        },
        "ok" : 1
}

Note that the user failed to acquire the "find" ActionType, which was recognized. This simulates what happens if a user creates custom roles with ActionTypes new to their version of MongoDB, then downgrades to the previous release.

The same logic handles roles modified through the oplog.

Comment by Spencer Brody (Inactive) [ 03/May/17 ]

Wasn't this already done as part of SERVER-21535?

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