[SERVER-83383] Add NamespaceFilter to AuthOpObserver Created: 17/Nov/23  Updated: 29/Nov/23  Resolved: 29/Nov/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.3.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Matt Kneiser Assignee: Matt Kneiser
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Backwards Compatibility: Fully Compatible
Sprint: Execution Team 2023-12-11
Participants:

 Description   

When initially implementing namespace filtering for OpObservers in SERVER-77364, there were four OpObservers that didn't filter on inserts.

Upon deeper review, I see that the AuthOpObserver which logs certain server operations, ultimately inspects the namespace of the operation and only cares about namespaces that the filter already provides for.

What makes this OpObserver extra expensive is that it does the namespace filtering for each element in a group of inserts, incurring an extra iteration over the list of inserts.

Therefore, we should be able to add a namespace filter (like this) to the AuthOpObserver to pull in a slight performance improvement in the hot-path of every insert to user collections.



 Comments   
Comment by Githook User [ 29/Nov/23 ]

Author:

{'name': 'Matt Kneiser', 'email': 'matt.kneiser@mongodb.com', 'username': 'themattman'}

Message: SERVER-83383 Add NamespaceFilter to AuthOpObserver
Branch: master
https://github.com/mongodb/mongo/commit/74858cb2b09383bf9be7903f63824f0da0f26ac4

Comment by Matt Kneiser [ 27/Nov/23 ]

Turning to the OpObserver's deleteFilter... (i.e. aboutToDelete & onDelete)

 

 

AuthOpObserver::aboutToDelete
-audit::logRemoveOperation
--audit::AuditInterface::logInsertOperation
---audit::AuditMongo::logInsertOperation
----audit::AuditMongo::logDirectAuthOperation
-----NamespaceString::isPrivilegeCollection

Same as inserts and updates.

 

and

 

AuthOpObserver::onDelete
-AuthorizationManager::logOp("d")

which as documented in a previous comment, deletes are handled the same as updates and inserts.

 

So both update and delete namespace filters can use the kSystem filter.

 

Comment by Matt Kneiser [ 27/Nov/23 ]

Ah, I realized the source of my confusion in the comments.
AuthOpObserver inspects each object and does two things with it, both of these operations do namespace checks.

audit::logInsertOperation
...
    nss.isPrivilegeCollection

isPrivilegeCollection filters down to:

admin.system.users or admin.system.roles

and

AuthManager::logOp("i")
 if (appliesToAuthzData)
   AuthzManagerExternalState::logOp

 

appliesToAuthzData comes down to:
inserts, updates, deletes: isAuthzNamespace (i.e. admin.system.roles, admin.system.users, admin.system.version){{{}
{}}}no-op: false
creates: loggedCommandOperatesOnAuthzData (i.e. in admin.$cmd)
else: true

In other words,
isAuthzNamespace & {{NamespaceString::isPrivilegeCollection
}}

The available filters are either for the config db, or system.* collections in any database. Thus, for onInserts we are safe with the OpObserver::NamespaceFilter::kSystem filter, however we need to look at onUpdate to ensure it is compatible with this filter.

audit::logUpdateOperation

This call gets to the same isPrivilegeCollection call before distinguishing operation type like AuditEventType::kUpdate/kInsert

and

AuthManager::logOp("u")

This call only cares about system collections just like inserts did above.

Generated at Thu Feb 08 06:52:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.