fix: match Mongo document permissions with exact strings - #940
Conversation
find/count/sum assembled an unescaped, case-insensitive regex from the
caller's roles. Role IDs may contain `.`, so a custom userId of
`alice.` matched every `read("user:alice?")` document. SQL already uses
an exact IN list; Mongo now does the same.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughMongoDB permission filters now use exact generated permission strings instead of case-insensitive regular expressions. Unit and end-to-end tests cover role formatting, case sensitivity, punctuation, and query operations. ChangesExact permission matching
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change makes Mongo document permission matching exact instead of regex-based and adds regression coverage; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe PR replaces MongoDB’s role-derived, case-insensitive permission regexes with exact permission-string filters, preventing regex metacharacters in role identifiers from broadening document access.
Confidence Score: 5/5The PR appears safe to merge, with the authorization fix consistently applied and no actionable regressions identified. Exact permission strings match the repository’s canonical persisted encoding, and the changed find, count, and sum paths preserve legitimate role behavior while removing regex-based overmatching. Important Files Changed
Reviews (1): Last reviewed commit: "fix: match Mongo document permissions wi..." | Re-trigger Greptile |
Problem
With document authorization enabled, the Mongo adapter built a regex from the caller’s role strings and used it as the
_permissions$infilter infind(),count(), andsum():Role identifiers are user-controlled (
user:<id>,team:<id>) andKey/UID/ AppwriteCustomIdall allow., which is the regex any-char wildcard. Theiflag also made matching case-insensitive.PoC (confirmed):
user:alice.matchesread("user:alice0")andread("user:alice9")user:a+ 19 dots matches any 20-char owner ID starting withaINon the perms table)Fix
Build
$inover exact permission strings (read("<role>")) at all three call-sites. NoRegex, noiflag.Tests
user:alice.cannot list/count/sum foreign docs;user:a+19 dots cannot mass-read; legitimateuser:alice0still worksalice.leakedalice0andalice9)Summary by CodeRabbit
Bug Fixes
Tests