[DOCS-14320] Investigate changes in SERVER-40569: Auditing "(NONE)" when address family is AF_UNSPEC Created: 29/Mar/21  Updated: 13/Nov/23  Resolved: 02/Apr/21

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 4.9.0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-40569 Auditing "(NONE)" when address family... Closed
Participants:
Days since reply: 2 years, 44 weeks, 5 days ago

 Description   

Description

Downstream Change Summary

We have removed auditing for commands invoked internally. When an external command causes the DBDirectClient to run a command, we used to audit these operations. Now we do not, reducing overall audit spam.

Description of Linked Ticket

When address family is AF_UNSPEC, we audit log ip: "(NONE)". It may be possible to treat this differently.

original description

When auditing is set on Mongodb, the log has local and remote IP which is always localhost as in:

Apr 10 11:17:27 CentOS50G tag1 { "atype" : "authCheck", "ts" : { "$date" : "2019-04-10T11:17:19.306-0700" }, "local" : { "ip" : "(NONE)", "port" : 0 }, "remote" : { "ip" : "(NONE)", "port" : 0 }, "users" : [], "roles" : [], "param" : { "command" : "listIndexes", "ns" : "config.system.sessions", "args" : { "listIndexes" : "system.sessions", "cursor" : {}, "$db" : "config" } }, "result" : 0 }

 Here eventhough Mongo server is CentOS50G the local ip is either NONE or 127.0.0.1 

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Jeffrey Allen [ 02/Apr/21 ]

This looks like a no-op for us. We don't make any mention of auditing for internal commands.

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