Add non-root user by default

[ToshY]

Fixes #679

Based on:

• Run container as an unprivileged user  #679 (comment)
• feat: run docker as non-root le-yak/dunglas-symfony-docker#1

---

Using a non-root user is regarded as a best practice.

I am not sure what the "many issues" a non-root user could cause (which might need further explanation), but I was able to build the images (dev/prod targets) and run it on dev without any apparent issues. Requires further testing.

[7-zete-7]

Hi, @ToshY!

Perhaps, instead of changing the Dockerfile, it would make sense to describe the changes to this PR in the documentation page?

[7-zete-7]

I assume FrankenPHP relies on Caddy's decision to run as root by default. See the discussion on this topic in the Caddy repository: caddyserver/caddy-docker#104.

[ToshY]

Hi, @ToshY!

Perhaps, instead of changing the Dockerfile, it would make sense to describe the changes to this PR in the documentation page?

Okay, would you recommend adding a (new) documentation page, or update an existing one?

Edit

I've moved it to a new documentation page.

---

I understand the decision to not directly apply the changes to the Dockerfile and document it instead. Maybe something to take into consideration for next time (and start with non-root by default then).

[7-zete-7]

This template's documentation files use simple diffs, not patches.

How about adding a couple of examples of using the new arguments?

[7-zete-7]

Why shouldn't the /app/var directory be a volume?

[ToshY]

While there are multiple considerations on why not to use VOLUME in the Dockerfile ¹, regarding the scope of the this feature, if docker would not be run as "rootless" (not to be confused with "running docker as non-root user"), if a volume mounted ./:/app (on development) but the ./var directory does not exist on host, this will create the ./var directory as root on host (which prevents the application from starting as the container user can not write to ./var).

Think this would either require the ./var to already be present on host (untested), or remove the VOLUME directive as done now (or the user should use docker "rootless" but this comes with possible side-effects). Maybe using the VOLUME would only be really useful for prod stage (for docker/compose in production; not kubernetes).

Footnotes

1. https://stackoverflow.com/a/55516433/9128538 ↩

[7-zete-7]

Interesting note. I can't find any simple ways to make this work while keeping this volume.

[ToshY]

@7-zete-7 There's one comment still open, and I fixed markdown linter errors in CI, but markdown prettier fails without denoting on why. What/where are the dev tools/linters/formatters to fix the formatting in such cases?

[7-zete-7]

According to https://github.com/dunglas/symfony-docker/actions/runs/18161075332/job/51691731657?pr=850:

• Strange BIOME_FORMAT and BIOME_LINT errors. Biome isn't in this repository. These are likely Super-Linter issue.

• EDITORCONFIG error:

  docs/non-root-user.md:
  	Wrong line endings or no final newline
  

  Previously, there was no final newline. Now there is. Does the file docs/non-root-user.md actually use LF line breaks?

• The MARKDOWN_PRETTIER error, I guess, is related to the file names are not separated from block codes by a empty line.

In diffs, it's important to use the formatting rules for the files for which edits are being proposed. For example, a Dockerfile should have tab indents. For its diff, the first column should be indented according to the diff rules, followed by tab indents. This will violate the MARKDOWNLINT MD010 rule, which should be disabled for this block of code. See

symfony-docker/docs/makefile.md

Lines 22 to 30 in 84aac83

	<!-- markdownlint-disable MD010 -->
	```diff
	gettext \
	git \
	+ make \
	```
	<!-- markdownlint-enable MD010 -->

[ToshY]

@7-zete-7

Fixed markdown issues. The markdown prettier does not show what is wrong (even in debug mode), so I ended up running the super-linter with docker locally, as it can also fix these issues directly.

docker run --rm -v $(pwd):/tmp/lint -e RUN_LOCAL=true -e DEFAULT_BRANCH=main -e LOG_LEVEL=DEBUG -e FIX_MARKDOWN=true -e FIX_MARKDOWN_PRETTIER=true  ghcr.io/super-linter/super-linter:slim-v8

The still failing biome checks are unrelated to the PR.

p.s.

Please consider adding this to (not yet existing) contributing guidelines so next time contributors can check how to easily run super-linter locally and fix these problems faster. I'm open to create another PR for this if desired.