-
Notifications
You must be signed in to change notification settings - Fork 6.8k
feat: exec policy integration in shell mcp #7609
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
Conversation
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
fb0cb00 to
e9a6dc4
Compare
e6b51aa to
a6eddba
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`.
a6eddba to
185e685
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`.
185e685 to
2d1a155
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`.
2d1a155 to
d0519b6
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
d0519b6 to
1b2b3ca
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
1b2b3ca to
212857d
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
212857d to
627e70d
Compare
|
@codex review |
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.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Ok(match evaluation.decision { | ||
| Decision::Forbidden => ExecPolicyOutcome::Forbidden, | ||
| Decision::Prompt => ExecPolicyOutcome::Prompt { | ||
| run_with_escalated_permissions: decision_driven_by_policy, | ||
| }, |
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.
Policy prompts are always escalated
When execpolicy yields Decision::Prompt, run_with_escalated_permissions is set whenever any non-heuristic rule matched, so determine_action will run the command via EscalateAction::Escalate after the user approves. That means an execpolicy rule that merely requests approval will cause the command to bypass the sandbox entirely once accepted, whereas the core execpolicy flow only bypasses the sandbox for explicit Allow rules (see core/src/exec_policy.rs where bypass_sandbox is tied to Decision::Allow). This over-escalates any prompted command defined in policy, weakening sandbox protections without the policy opting into it.
Useful? React with 👍 / 👎.
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
627e70d to
fd8d68a
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
fd8d68a to
aa58369
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
aa58369 to
d65dd48
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
d65dd48 to
be05876
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
be05876 to
1ef31fc
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
1ef31fc to
4c23d0b
Compare
…7615) The caller should decide whether wrapping the policy in `Arc<RwLock>` is necessary. This should make #7609 a bit smoother. - `exec_policy_for()` -> `load_exec_policy_for_features()` - introduce `load_exec_policy()` that does not take `Features` as an arg - both return `Result<Policy, ExecPolicyError>` instead of Result<Arc<RwLock<Policy>>, ExecPolicyError>` This simplifies the tests as they have no need for `Arc<RwLock>`. .
4c23d0b to
f1ddea3
Compare
| let evaluation = policy.check(&command, &|cmd| { | ||
| if command_might_be_dangerous(cmd) { | ||
| Decision::Prompt | ||
| } else { | ||
| Decision::Allow | ||
| } | ||
| }); |
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 HeuristicsFallback abstraction feels weird to me. I'm going to revisit in a follow-up.
bolinfest
left a comment
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.
Let's get this in and I can change, as necessary.
adding execpolicy support into the
posixmcp