mediumContainers and deployment files

World-Writable Permissions in the Image

Files in the image are writable by everyone.

Why it matters

777 is usually added to make a permission error go away. The real issue is that the process user does not own the directory it writes to. Giving that user ownership of just the directories it needs fixes the error without opening every file to every process.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

Recursive 777

RUN chmod -R 777 /app

The smallest fix

minimal patch

# Before
RUN chmod -R 777 /app
# After: own what the app writes to, nothing more
RUN mkdir -p /app/uploads && chown -R app:app /app/uploads
USER app

The better fix

If you have a few more minutes, this is the approach that holds up as the app grows.

safe alternative

# Use COPY --chown=app:app for application files so no chmod is needed,
# and mount writable paths as volumes owned by the app user.

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

In [the file] at line [the line number] permissions are opened to everyone: [the flagged code]. Remove the chmod, identify the directories the process actually writes to, chown those to the unprivileged user the container runs as, and use COPY --chown for application files.

How to check the fix worked

1. Run the app and exercise the feature that writes files; confirm no
   permission errors.
2. Run `find / -perm -o+w -type f` in the container and confirm no
   application files are listed.