-
Notifications
You must be signed in to change notification settings - Fork 5.9k
feat(permissions): allow flags should override deny when more specific #31224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(permissions): allow flags should override deny when more specific #31224
Conversation
Co-authored-by: Copilot <[email protected]> Signed-off-by: David Sherret <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR refactors the permission system to improve handling of granular allow and deny rules. The main change replaces separate HashSet-based storage for granted, flag-denied, and prompt-denied descriptors with a unified sorted vector-based approach, enabling more precise permission resolution with partial denials.
- Changed data structure from
HashSet-based to sortedVec-based descriptor storage - Added
DeniedPartialstate to distinguish between full and partial denials - Implemented comparison traits for descriptor ordering to support binary search
Reviewed Changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| runtime/permissions/lib.rs | Core refactoring: unified descriptor storage, added sorting/comparison logic, implemented partial denial handling |
| runtime/permissions/Cargo.toml | Added test features for sys_traits dependency |
| runtime/ops/permissions.rs | Updated PermissionStatus to use static string for state and handle DeniedPartial |
| libs/config/deno_json/permissions.rs | Added helper method and simplified empty check logic |
| cli/args/mod.rs | Renamed variable from no_op to identity for clarity |
| Cargo.toml | Updated fqdn dependency from 0.3.4 to 0.4.6 |
| Cargo.lock | Updated fqdn package checksum and version |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| state.to_string() | ||
| state: match state { | ||
| PermissionState::Granted | PermissionState::GrantedPartial => "granted", | ||
| PermissionState::DeniedPartial | PermissionState::Denied => "denied", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This DeniedPartial isn't used at the moment, but it's useful granularity to have. I'll use it in a future PR that I extract out of #31187
Co-authored-by: Copilot <[email protected]> Signed-off-by: David Sherret <[email protected]>
|
|
||
| impl PermissionsObject { | ||
| /// Returns true if the permissions object is empty (no permissions are set). | ||
| pub fn is_empty(&self) -> bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I probably asked this in the past - but aren't we calling this in a hot path? Maybe this value should be memoized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is only used in a few select places (I think one place). If it were in runtime/permissions then yeah it could be in a hot path.
runtime/permissions/lib.rs
Outdated
| PermissionState::GrantedPartial => f.pad("granted-partial"), | ||
| PermissionState::Prompt => f.pad("prompt"), | ||
| PermissionState::Denied => f.pad("denied"), | ||
| PermissionState::Denied | PermissionState::DeniedPartial => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not discriminate denied-partial?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems this is not used so I will remove it.
| UnaryPermissionDesc::FlagDenied(_) => 0, | ||
| UnaryPermissionDesc::PromptDenied(_) => 1, | ||
| UnaryPermissionDesc::Granted(_) => 2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does "flag denied" have a higher precedence than "prompt denied"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One needed to be higher than the other and flag seems a little more higher precedence than prompt.
Co-authored-by: Bartek Iwańczuk <[email protected]> Signed-off-by: David Sherret <[email protected]>
| { | ||
| let perms = Permissions::from_options( | ||
| &parser, | ||
| &PermissionsOptions { | ||
| allow_read: Some(svec!["/foo/specific"]), | ||
| deny_read: Some(svec!["/foo"]), | ||
| allow_write: Some(svec!["/foo/specific"]), | ||
| deny_write: Some(svec!["/foo"]), | ||
| allow_ffi: Some(svec!["/foo/specific"]), | ||
| deny_ffi: Some(svec!["/foo"]), | ||
| ..Default::default() | ||
| }, | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add another test case, that flips the values (ie. allow_read: Some(svec!["/foo"]), deny_read: Some(svec!["/foo/specific"])) - just to be extra sure that reading /foo/bar is allowed but /foo/specific is not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in 8185f89
| assert_eq!( | ||
| perms.env.query(Some("PREFIX_TEST")), | ||
| PermissionState::Denied | ||
| ); | ||
| assert_eq!( | ||
| perms.env.query(Some("PREFIX_ALLOWED_TEST")), | ||
| PermissionState::Granted | ||
| ); | ||
| assert_eq!( | ||
| perms.env.query(Some("PREFIX_EXPLICIT_ALLOWED")), | ||
| PermissionState::Granted | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Allow flags that are more specific than deny flags should take precedence.
Some examples:
--allow-read=./data/sub --deny-read=./data--allow-env=NODE_ENV --deny-read=NODE_*Extracted out of #31187 -- This behaviour will be more important when the
--ingore-envflag is added in order to make the feature more powerful.