[SERVER-45888] $lookup unnecessarily requires 'find' privilege even if sub-pipeline does not read from 'from' collection Created: 30/Jan/20 Updated: 06/Dec/22 Resolved: 04/Feb/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 3.6.17, 4.2.3, 4.0.15 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | qopt-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query
|
|
| Operating System: | ALL | |
| Steps To Reproduce: | As an example, consider a user with only the 'collStats' privilege on the 'test.foo' namespace and 'find' privilege on 'test.bar'. An aggregation such as
Should not fail with an authorization failure. |
|
| Participants: |
| Description |
|
There is no restriction on having an "initial source" stage (e.g. $collStats, $planCacheStats, ...) within a $lookup sub-pipeline, which means the operation may not perform a read against the 'from' collection. In such a case, the aggregation should not require the 'find' privilege on the 'from' collection. |
| Comments |
| Comment by Charlie Swanson [ 04/Feb/20 ] |
|
We think the problem is that the required permissions are too strict, so there's no security vulnerability here. Because of this, the query team is declining to fix this on older branches. This decision can be re-evaluated if someone really wants this. |