[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: |
|
||||||||||||||||||||||||||||||||
| 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! |
| 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. |