[SERVER-8935] Provide a mechanism for mongos to tell shard mongods which user every action is being performed on behalf of Created: 11/Mar/13  Updated: 09/Oct/18  Resolved: 02/Oct/18

Status: Closed
Project: Core Server
Component/s: Security, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Jonathan Reams
Resolution: Duplicate Votes: 2
Labels: platforms-re-triaged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-7538 When using profiling on a sharded sys... Backlog
Duplicate
duplicates SERVER-5261 Include authentication information in... Closed
Related
related to SERVER-5261 Include authentication information in... Closed
is related to SERVER-8876 DDL and Authentication Audit Logs Closed
is related to SERVER-7942 Mongo servers should fail at startup ... Closed
Sprint: Security 2018-10-08
Participants:

 Description   

Every connection from mongos to mongod is authenticated using the internal __system user. This means that the mongods have no idea what user was authenticated to the connection to the mongos that actually initiated the request they are performing work to respond to. Perhaps a field in the wire protocol could be used for each request to tell the shard what user initiated this request? This would allow shard mongods to use that information in things like logging, profiling, auditing, etc.



 Comments   
Comment by Spencer Jackson [ 10/Nov/17 ]

No, non-enterprise builds do not. Fair enough, re-assigning.

Comment by Andy Schwerin [ 10/Nov/17 ]

spencer.jackson, do non-enterprise builds of mongodb transmit the user information over the wire? That's the only request in this ticket, I think, so I'd guess it belongs to the platforms backlog.

Comment by Eric Milkie [ 21/May/15 ]

This feature was already made available in auditing; it's not yet used for user-level profiling however.

Comment by Kay Agahd [ 21/May/15 ]

The prio is now Major - P3 but there is no progress for over 2 years already! Could you solve this issue eventually please?

Comment by Kay Agahd [ 30/Oct/13 ]

I'm surprised that this issue is flagged as "a feature we're not sure of" because SERVER-7538 depends on this and SERVER-7538 is a major bug!
Please fix it because it's very important to know the users of profiled slow queries in a sharded system.
Thanks!

Comment by Andy Schwerin [ 07/May/13 ]

I think I'd rather get a master operation id that I can use to look through all the audit logs, to find all the events related to a single operation.

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