Skip to content

fix(readonly-unix): exclude arbitrary execution and file write options via negation#10

Merged
fohte merged 5 commits intomainfrom
fohte/fix-find-exec-negation
Mar 9, 2026
Merged

fix(readonly-unix): exclude arbitrary execution and file write options via negation#10
fohte merged 5 commits intomainfrom
fohte/fix-find-exec-negation

Conversation

@fohte
Copy link
Owner

@fohte fohte commented Mar 9, 2026

Why

  • Multiple command patterns in readonly-unix.yml did not exclude options that allow arbitrary command execution or file writes
    • find: -exec, -execdir, -ok, -okdir (arbitrary command execution)
    • fd: -x/--exec, -X/--exec-batch (arbitrary command execution)
    • rg: --pre (arbitrary command execution via preprocessor)
    • ag/ack: --pager (arbitrary command execution)
    • bat: --pager (arbitrary command execution)
    • man: -P/--pager (arbitrary command execution)
    • sort: --compress-program (arbitrary command execution)
    • tar: --use-compress-program, --checkpoint-action (arbitrary command execution)
    • less: -o/-O/--log-file/--LOG-FILE (file writes)
  • bc, dc, and ldd were in the allow list despite having inherent command execution risks that cannot be controlled through CLI argument matching

What

  • Add negation patterns to each command to exclude options that allow arbitrary command execution or file writes
  • Remove bc, dc, and ldd from the allow list
  • Add E2E tests and update the resolved KNOWN ISSUE test case

The find pattern used a wildcard `*` that matched any remaining
arguments, allowing `find . -exec rm {} \;` to be allowed despite
being a read-only preset. These four options can execute arbitrary
commands, so they must be excluded via negation to prevent unintended
command execution in readonly-unix.yml (and base.yml which extends it).

Also update the base.yml KNOWN ISSUE test case that is now resolved,
and add E2E tests for all four negated options.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@gemini-code-assist
Copy link

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical security vulnerability in the readonly-unix.yml configuration by preventing the find command from executing arbitrary commands via its -exec family options. The changes enhance the security posture by explicitly disallowing these potentially dangerous operations. Comprehensive end-to-end tests have been introduced and an existing test case updated to validate the effectiveness of this security enhancement.

Highlights

  • Security Fix for find command: The readonly-unix.yml configuration has been updated to explicitly negate the -exec, -execdir, -ok, and -okdir options within find commands. Previously, a wildcard allowed these options, posing a security risk by permitting arbitrary command execution.
  • New End-to-End Tests: New E2E tests have been added to tests/test-cases.yml to verify that find commands utilizing the newly negated -exec family options are correctly flagged as 'ask' (requiring user confirmation), ensuring the security fix is effective.
  • Updated Known Issue Test Case: An existing test case in tests/test-cases.yml for find . -name "*.log" -exec rm {} \; has been updated. It now correctly expects an 'ask' response, resolving a previously identified 'KNOWN ISSUE' where it was incorrectly allowed.
Changelog
  • readonly-unix.yml
    • Modified the find allow rule to include -exec, -execdir, -ok, and -okdir in its negation pattern, preventing arbitrary command execution.
  • tests/test-cases.yml
    • Added new test cases for find commands using -exec, -execdir, -ok, and -okdir to ensure they are correctly blocked.
    • Updated an existing test case for find -exec rm to reflect the new, secure behavior, changing its expected outcome from 'allow' to 'ask' and updating its description.
Activity
  • No human activity has been recorded on this pull request yet.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

@devin-ai-integration devin-ai-integration bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

Open in Devin Review

gemini-code-assist[bot]

This comment was marked as resolved.

… commands

Several commands in readonly-unix.yml allowed arbitrary command
execution or file writes through options that the wildcard `*`
matched without restriction.

Add negation patterns for:
- less: -o/-O/--log-file/--LOG-FILE (file writes)
- fd: -x/--exec/-X/--exec-batch (command execution)
- rg: --pre (command execution via preprocessor)
- ag/ack: --pager (command execution)
- sort: --compress-program (command execution)
- tar: --use-compress-program/--checkpoint-action (command execution)

Also add a comment documenting ldd's known binary execution risk.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@fohte fohte changed the title fix(readonly-unix): add -exec family options to find pattern negation fix(readonly-unix): exclude arbitrary execution and file write options via negation Mar 9, 2026
fohte and others added 2 commits March 10, 2026 01:25
bat's --pager and man's -P/--pager options allow arbitrary command
execution by specifying a custom pager program.

GNU bc has a system() built-in function and GNU dc has a ! command,
both allowing arbitrary command execution via language-internal
features that cannot be controlled through CLI argument matching
(same limitation as awk/gawk).

Co-Authored-By: Claude Opus 4.6 <[email protected]>
Remove comments explaining why awk/gawk and bc/dc are not in the
allow list — absent entries do not need documentation.

Remove ldd because it may execute the target binary to resolve
dependencies on Linux, which violates the read-only principle.

Co-Authored-By: Claude Opus 4.6 <[email protected]>
@fohte fohte merged commit b0d91df into main Mar 9, 2026
4 checks passed
@fohte fohte deleted the fohte/fix-find-exec-negation branch March 9, 2026 18:10
@fohte-bot fohte-bot bot mentioned this pull request Mar 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant