[GH-ISSUE #87] Report writing permission issues #28

New issue

Closed

opened 2026-02-27 07:20:04 +03:00 by kerem · 4 comments

kerem commented 2026-02-27 07:20:04 +03:00

Owner

Copy link

Originally created by @st3fan on GitHub (Feb 7, 2026).
Original GitHub issue: https://github.com/KeygraphHQ/shannon/issues/87

Running on Debian Trixie as a regular user:

[2026-02-07 22:56:16] [pre-recon] [LLM] Turn 211: The deliverables directory doesn't exist. Let me create it first:
[2026-02-07 22:56:17] [pre-recon] [LLM] Turn 212: {"type":"tool_use","id":"toolu_019fc62tEu4QZ8XoDhRCEzQV","name":"Bash","input":{"command":"mkdir -p /target-repo/deliverables","description":"Create deliverables directory"}}
[2026-02-07 22:58:20] [pre-recon] [LLM] Turn 213: Let me check the current directory structure:
[2026-02-07 22:58:20] [pre-recon] [LLM] Turn 214: {"type":"tool_use","id":"toolu_01BUR55BCNG4aEnvcg7DfXRx","name":"Bash","input":{"command":"pwd && ls -la","description":"Check current directory and permissions"}}
[2026-02-07 22:58:23] [pre-recon] [LLM] Turn 215: Let me try creating the directory with sudo or as the correct user:
[2026-02-07 22:58:24] [pre-recon] [LLM] Turn 216: {"type":"tool_use","id":"toolu_01P9q5iVmGqjvjtRcNsdMCEA","name":"Bash","input":{"command":"mkdir -p deliverables && ls -la deliverables","description":"Create deliverables directory in current location"}}
[2026-02-07 22:58:26] [pre-recon] [LLM] Turn 217: Let me check who I am and try with proper permissions:
[2026-02-07 22:58:27] [pre-recon] [LLM] Turn 218: {"type":"tool_use","id":"toolu_01QFD1WyX8AghF1F6AMpyMRw","name":"Bash","input":{"command":"whoami && id && ls -ld /target-repo","description":"Check current user and directory permissions"}}
[2026-02-07 22:58:29] [pre-recon] [LLM] Turn 219: The target-repo directory is owned by UID 1000, but I'm running as UID 1001. Let me try creating the directory with sudo:
[2026-02-07 22:58:30] [pre-recon] [LLM] Turn 220: {"type":"tool_use","id":"toolu_01NakXphyxaE1ytNZzW2nCAb","name":"Bash","input":{"command":"sudo mkdir -p /target-repo/deliverables && sudo chown pentest:pentest /target-repo/deliverables && ls -la /target-repo/deliverables","description":"Create deliverables directory with sudo and change ownership"}}
[2026-02-07 22:58:33] [pre-recon] [LLM] Turn 221: Let me check if there's an outputs directory instead or use /tmp:
[2026-02-07 22:58:35] [pre-recon] [LLM] Turn 222: {"type":"tool_use","id":"toolu_01Cusye4xpwP1vAuTnCKWYKj","name":"Bash","input":{"command":"ls -la / | grep -E \"(deliverables|outputs|tmp)\" && mkdir -p /tmp/deliverables && ls -la /tmp/deliverables","description":"Check for existing directories and create in /tmp"}}
[2026-02-07 22:58:38] [pre-recon] [LLM] Turn 223: Good! I can write to /tmp. Now let me save the deliverable there and then check if the MCP tool can handle it:

The relvant bits here are:

[2026-02-07 22:58:27] [pre-recon] [LLM] Turn 218: {"type":"tool_use","id":"toolu_01QFD1WyX8AghF1F6AMpyMRw","name":"Bash","input":{"command":"whoami && id && ls -ld /target-repo","description":"Check current user and directory permissions"}}

[2026-02-07 22:58:29] [pre-recon] [LLM] Turn 219: The target-repo directory is owned by UID 1000, but I'm running as UID 1001. Let me try creating the directory with sudo:

Originally created by @st3fan on GitHub (Feb 7, 2026). Original GitHub issue: https://github.com/KeygraphHQ/shannon/issues/87 Running on Debian Trixie as a regular user: ``` [2026-02-07 22:56:16] [pre-recon] [LLM] Turn 211: The deliverables directory doesn't exist. Let me create it first: [2026-02-07 22:56:17] [pre-recon] [LLM] Turn 212: {"type":"tool_use","id":"toolu_019fc62tEu4QZ8XoDhRCEzQV","name":"Bash","input":{"command":"mkdir -p /target-repo/deliverables","description":"Create deliverables directory"}} [2026-02-07 22:58:20] [pre-recon] [LLM] Turn 213: Let me check the current directory structure: [2026-02-07 22:58:20] [pre-recon] [LLM] Turn 214: {"type":"tool_use","id":"toolu_01BUR55BCNG4aEnvcg7DfXRx","name":"Bash","input":{"command":"pwd && ls -la","description":"Check current directory and permissions"}} [2026-02-07 22:58:23] [pre-recon] [LLM] Turn 215: Let me try creating the directory with sudo or as the correct user: [2026-02-07 22:58:24] [pre-recon] [LLM] Turn 216: {"type":"tool_use","id":"toolu_01P9q5iVmGqjvjtRcNsdMCEA","name":"Bash","input":{"command":"mkdir -p deliverables && ls -la deliverables","description":"Create deliverables directory in current location"}} [2026-02-07 22:58:26] [pre-recon] [LLM] Turn 217: Let me check who I am and try with proper permissions: [2026-02-07 22:58:27] [pre-recon] [LLM] Turn 218: {"type":"tool_use","id":"toolu_01QFD1WyX8AghF1F6AMpyMRw","name":"Bash","input":{"command":"whoami && id && ls -ld /target-repo","description":"Check current user and directory permissions"}} [2026-02-07 22:58:29] [pre-recon] [LLM] Turn 219: The target-repo directory is owned by UID 1000, but I'm running as UID 1001. Let me try creating the directory with sudo: [2026-02-07 22:58:30] [pre-recon] [LLM] Turn 220: {"type":"tool_use","id":"toolu_01NakXphyxaE1ytNZzW2nCAb","name":"Bash","input":{"command":"sudo mkdir -p /target-repo/deliverables && sudo chown pentest:pentest /target-repo/deliverables && ls -la /target-repo/deliverables","description":"Create deliverables directory with sudo and change ownership"}} [2026-02-07 22:58:33] [pre-recon] [LLM] Turn 221: Let me check if there's an outputs directory instead or use /tmp: [2026-02-07 22:58:35] [pre-recon] [LLM] Turn 222: {"type":"tool_use","id":"toolu_01Cusye4xpwP1vAuTnCKWYKj","name":"Bash","input":{"command":"ls -la / | grep -E \"(deliverables|outputs|tmp)\" && mkdir -p /tmp/deliverables && ls -la /tmp/deliverables","description":"Check for existing directories and create in /tmp"}} [2026-02-07 22:58:38] [pre-recon] [LLM] Turn 223: Good! I can write to /tmp. Now let me save the deliverable there and then check if the MCP tool can handle it: ``` The relvant bits here are: ``` [2026-02-07 22:58:27] [pre-recon] [LLM] Turn 218: {"type":"tool_use","id":"toolu_01QFD1WyX8AghF1F6AMpyMRw","name":"Bash","input":{"command":"whoami && id && ls -ld /target-repo","description":"Check current user and directory permissions"}} [2026-02-07 22:58:29] [pre-recon] [LLM] Turn 219: The target-repo directory is owned by UID 1000, but I'm running as UID 1001. Let me try creating the directory with sudo: ```

kerem closed this issue 2026-02-27 07:20:04 +03:00

kerem commented 2026-02-27 07:20:05 +03:00

Author

Owner

Copy link

@mikegogulski commented on GitHub (Feb 8, 2026):

I'm getting this too, stuff like:

The tool insists on looking for a file at `/target-repo/deliverables/code_analysis_deliverable.md`.
Since I cannot create this directory structure, and the file_path parameter is an alternative, let
me inform the user about the situation and provide the report directly:

which seems to imply that there should be a place where a target-repo directory can be created. My installation has the repo owned by one user but shannon installed in a different user account.

<!-- gh-comment-id:3865894019 --> @mikegogulski commented on GitHub (Feb 8, 2026): I'm getting this too, stuff like: ``` The tool insists on looking for a file at `/target-repo/deliverables/code_analysis_deliverable.md`. Since I cannot create this directory structure, and the file_path parameter is an alternative, let me inform the user about the situation and provide the report directly: ``` which seems to imply that there should be a place where a `target-repo` directory can be created. My installation has the repo owned by one user but shannon installed in a different user account.

kerem commented 2026-02-27 07:20:05 +03:00

Author

Owner

Copy link

@st3fan commented on GitHub (Feb 8, 2026):

I see in the logs that it wrote things to /tmp/deliverables/code_analysis_deliverable.md now but that file is nowhere to be found. Maybe it is in a docker volume?

<!-- gh-comment-id:3866042096 --> @st3fan commented on GitHub (Feb 8, 2026): I see in the logs that it wrote things to `/tmp/deliverables/code_analysis_deliverable.md` now but that file is nowhere to be found. Maybe it is in a docker volume?

kerem commented 2026-02-27 07:20:05 +03:00

Author

Owner

Copy link

@bubududukuh commented on GitHub (Feb 8, 2026):

test

<!-- gh-comment-id:3867144604 --> @bubududukuh commented on GitHub (Feb 8, 2026): test

kerem commented 2026-02-27 07:20:05 +03:00

Author

Owner

Copy link

@Yash-xoxo commented on GitHub (Feb 9, 2026):

Hey @st3fan and @mikegogulski,

I've run into similar permission issues with dockerized tools before, and this looks like a classic UID mismatch problem combined with volume mounting confusion.

What's Happening

From the logs, the issue is pretty clear:

• The /target-repo directory is owned by UID 1000 (probably the host user who cloned the repo)
• Shannon is running as UID 1001 inside the container (the pentest user based on the logs)
• When Claude tries to write the deliverables, it doesn't have permission to create /target-repo/deliverables

The tool eventually falls back to /tmp/deliverables/code_analysis_deliverable.md, but as you noticed, that file "disappears" because it's written inside the container's filesystem, not to a mounted volume.

Why /tmp Files Disappear

When Claude writes to /tmp/deliverables/ inside the container, that's not a mounted volume - it's just the container's internal filesystem. Once the container stops or the analysis completes, that data is gone unless /tmp is explicitly mounted.

Suggested Fixes

Option 1: Fix the UID Mapping (Recommended)

Update the Docker run command or docker-compose to match UIDs:

# If running with docker run, add:
docker run --user $(id -u):$(id -g) ...

# Or in docker-compose.yml:
services:
  shannon:
    user: "${UID}:${GID}"

Then make sure the target repo is readable by that user:

chmod -R u+rw /path/to/target-repo

Option 2: Mount a Deliverables Volume

Add an explicit volume mount for deliverables output:

# In docker run:
-v /path/on/host/deliverables:/target-repo/deliverables

# Or in docker-compose.yml:
volumes:
  - ./deliverables:/target-repo/deliverables

Create the directory first with proper permissions:

mkdir -p ./deliverables
chmod 777 ./deliverables  # Or set to proper user ownership

Option 3: Use a Dedicated Output Directory

Instead of trying to write to /target-repo/deliverables, configure Shannon to use a separate output directory that's properly mounted:

# Mount it separately
-v /path/on/host/output:/output

# And make sure it's writable
chmod 777 /path/on/host/output

Then maybe update the prompts/config to tell Claude to use /output instead of /target-repo/deliverables.

Quick Workaround

For immediate testing, you could:

1. Run the container with elevated permissions (not great, but works):

docker run --privileged ...
# or
--user root

2. After analysis completes, manually extract files from the container:

docker cp <container_id>:/tmp/deliverables/. ./deliverables/

3. Change ownership of the target-repo before running:

sudo chown -R 1001:1001 /target-repo

Long-term Solution

The codebase should probably:

1. Have a configurable output directory (env var like SHANNON_OUTPUT_DIR)
2. Check permissions early and fail fast with a clear error message
3. Document the volume mounting requirements in the README

Would you want me to submit a PR to add better error handling for this? I could add a startup check that verifies write permissions to the expected output directory and gives a clear error message with suggested fixes.

Let me know which approach works best for your setup!

<!-- gh-comment-id:3872104048 --> @Yash-xoxo commented on GitHub (Feb 9, 2026): Hey @st3fan and @mikegogulski, I've run into similar permission issues with dockerized tools before, and this looks like a classic UID mismatch problem combined with volume mounting confusion. ## What's Happening From the logs, the issue is pretty clear: - The `/target-repo` directory is owned by UID 1000 (probably the host user who cloned the repo) - Shannon is running as UID 1001 inside the container (the `pentest` user based on the logs) - When Claude tries to write the deliverables, it doesn't have permission to create `/target-repo/deliverables` The tool eventually falls back to `/tmp/deliverables/code_analysis_deliverable.md`, but as you noticed, that file "disappears" because it's written inside the container's filesystem, not to a mounted volume. ## Why `/tmp` Files Disappear When Claude writes to `/tmp/deliverables/` inside the container, that's not a mounted volume - it's just the container's internal filesystem. Once the container stops or the analysis completes, that data is gone unless `/tmp` is explicitly mounted. ## Suggested Fixes ### Option 1: Fix the UID Mapping (Recommended) Update the Docker run command or docker-compose to match UIDs: ```bash # If running with docker run, add: docker run --user $(id -u):$(id -g) ... # Or in docker-compose.yml: services: shannon: user: "${UID}:${GID}" ``` Then make sure the target repo is readable by that user: ```bash chmod -R u+rw /path/to/target-repo ``` ### Option 2: Mount a Deliverables Volume Add an explicit volume mount for deliverables output: ```bash # In docker run: -v /path/on/host/deliverables:/target-repo/deliverables # Or in docker-compose.yml: volumes: - ./deliverables:/target-repo/deliverables ``` Create the directory first with proper permissions: ```bash mkdir -p ./deliverables chmod 777 ./deliverables # Or set to proper user ownership ``` ### Option 3: Use a Dedicated Output Directory Instead of trying to write to `/target-repo/deliverables`, configure Shannon to use a separate output directory that's properly mounted: ```bash # Mount it separately -v /path/on/host/output:/output # And make sure it's writable chmod 777 /path/on/host/output ``` Then maybe update the prompts/config to tell Claude to use `/output` instead of `/target-repo/deliverables`. ## Quick Workaround For immediate testing, you could: 1. Run the container with elevated permissions (not great, but works): ```bash docker run --privileged ... # or --user root ``` 2. After analysis completes, manually extract files from the container: ```bash docker cp <container_id>:/tmp/deliverables/. ./deliverables/ ``` 3. Change ownership of the target-repo before running: ```bash sudo chown -R 1001:1001 /target-repo ``` ## Long-term Solution The codebase should probably: 1. Have a configurable output directory (env var like `SHANNON_OUTPUT_DIR`) 2. Check permissions early and fail fast with a clear error message 3. Document the volume mounting requirements in the README Would you want me to submit a PR to add better error handling for this? I could add a startup check that verifies write permissions to the expected output directory and gives a clear error message with suggested fixes. Let me know which approach works best for your setup!

kerem referenced this issue 2026-02-27 07:20:20 +03:00

[PR #28] [CLOSED] feat: Add local Ollama AI support with browser automation #77

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

feat/npx-integration

Readme-Update

feat/telemetry

ctf-mode

v1.1.0

v1.0.0

Labels

Clear labels   

pull-request

Mirrored from GitHub Pull Request

No labels

pull-request

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/shannon-KeygraphHQ#28

No description provided.