Run container as an unprivileged user

[damienfern]

Hi,

Thx for this template, very useful ! 🙏

Many resources suggest using an unprivileged user in container in order to prevent privilege escalation attacks(e.g. OWASP https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html#rule-2-set-a-user or Docker docs https://docs.docker.com/build/building/best-practices/#user).

It seems it's not the case on this template with FrankenPHP and based on its doc, FrankenPHP can be used with an unprivileged user. Is it on purpose, or is it a feature that can be added to this template ?

[7-zete-7]

Hi, @damienfern

I'm also interested in this question!

For now I'm using the following edits to run FrankenPHP as the built-in user www-data.

frankenphp/docker-entrypoint.sh

@@ -53,8 +53,9 @@
 		fi
 	fi
 
-	setfacl -R -m u:www-data:rwX -m u:"$(whoami)":rwX var
-	setfacl -dR -m u:www-data:rwX -m u:"$(whoami)":rwX var
+	chgrp -R www-data var /data /config
+	setfacl -R -m u:www-data:rwX -m u:"$(whoami)":rwX var /data /config
+	setfacl -dR -m u:www-data:rwX -m u:"$(whoami)":rwX var /data /config
 fi
 
-exec docker-php-entrypoint "$@"
+su -c "docker-php-entrypoint $*" -s '/bin/sh' 'www-data'

With this edit the container still runs as root, but FrankenPHP runs as www-data.

I'm not sure if this is the correct way, but in my case it works so far.

I would also be glad if this template contained information about a more correct way to run the container not as an privileged user.

[dunglas]

Modifying the Dockerfile like this should help: https://frankenphp.dev/docs/docker/#running-as-a-non-root-user

A doc PR explaining how to change this template to run as a non-root user is very welcome, however, we'll not do that by default, because this causes many issues.

[7-zete-7]

Found a problem when using the method I described above (using su ... instead of exec ...): when using su ... a chain of subprocesses is created (entrypoint→su→sh→frankenphp), while when using exec ... there is no chain (frankenphp).

Due to the chain, signals sent by Docker do not reach the target process. This primarily negatively affects the Symfony Messenger consumer.

Processes when using exec ...:

PID	USER	Command
1	root	frankenphp run --config /etc/caddy/Caddyfile

Processes when using su ...:

PID	USER	Command
1	root	/bin/sh /usr/local/bin/docker-entrypoint frankenphp run --config /etc/caddy/Caddyfile
33	root	`- su -c docker-php-entrypoint frankenphp run --config /etc/caddy/Caddyfile -s /usr/bin/sh www-data
34	www‑data	`- sh -c frankenphp run --config /etc/caddy/Caddyfile
35	www‑data	`- frankenphp run --config /etc/caddy/Caddyfile

[damienfern]

Hi @7-zete-7,

You should give a try to https://github.com/tianon/gosu as it uses the same methods to "impersonate" user as Docker, but it uses an exec instead of a subprocess (which, as you pointed, handles the signal better).

[7-zete-7]

Thanks for such a quick response, @damienfern!

I'll try using gosu for this task.

[7-zete-7]

gosu actually changes the user and does not create any subprocesses. Thanks, @damienfern!

[7-zete-7]

Some update of #679 (comment) to work via gosu.

Dockerfile

@@ -20,6 +20,7 @@
 RUN apt-get update && apt-get install -y --no-install-recommends \
 	acl \
 	file \
 	gettext \
 	git \
+	gosu \
 	&& rm -rf /var/lib/apt/lists/*

frankenphp/docker-entrypoint.sh

@@ -53,8 +53,9 @@
 		fi
 	fi
 
-	setfacl -R -m u:www-data:rwX -m u:"$(whoami)":rwX var
-	setfacl -dR -m u:www-data:rwX -m u:"$(whoami)":rwX var
+	chgrp -R www-data var /data /config
+	setfacl -R -m u:www-data:rwX -m u:"$(whoami)":rwX var /data /config
+	setfacl -dR -m u:www-data:rwX -m u:"$(whoami)":rwX var /data /config
 fi
 
-exec docker-php-entrypoint "$@"
+exec /usr/sbin/gosu www-data "$@"

Still not sure if this is the correct way, but it works for now.

[damienfern]

Have you tried to use gosu directly ? Based on the gosu's README, it already does an exec.

-exec /usr/sbin/gosu www-data "$@"
+/usr/sbin/gosu www-data "$@"

[7-zete-7]

@damienfern, yes, I did this first. I was surprised that there was a chain of processes and tried with exec. With exec the chain was gone.

Using exec /usr/sbin/gosu www-data "$@"

PID	USER	Command
1	www-data	frankenphp run --config /etc/caddy/Caddyfile

Using /usr/sbin/gosu www-data "$@" or gosu www-data "$@"

PID	USER	Command
1	root	/bin/sh /usr/local/bin/docker-entrypoint frankenphp run --config /etc/caddy/Caddyfile
20	www-data	`- frankenphp run --config /etc/caddy/Caddyfile

[jeanatpi]

Modifying the Dockerfile like this should help: https://frankenphp.dev/docs/docker/#running-as-a-non-root-user

A doc PR explaining how to change this template to run as a non-root user is very welcome, however, we'll not do that by default, because this causes many issues.

Hi Dunglas,

can you explain which issues this can cause (or point me to a link where I can find it) ?

We have adopted this template approach for our local env but when running a command inside the container, like creating a migration, file is generated as root and then it creates issues when you want to commit it, switch branch, etc.

Are we missing something in the way we use this template ?

[7-zete-7]

Hi @jeanatpi!

can you explain which issues this can cause (or point me to a link where I can find it) ?

CC @dunglas @maxhelias

IMO the use of superuser in this template is for the purpose of simplification.

Running FrankenPHP in a prod container without superuser will lead to difficulties in setting up permissions. The options proposed in this thread represent only a basic setup. Using these options can lead to errors in the container, project and FrankenPHP.

Using this template for development without superuser will create many difficulties, as some operations inside the container require superuser rights. Setting up user juggling is possible, but it will be more complicated than doing it for a prod environment.

We have adopted this template approach for our local env but when running a command inside the container, like creating a migration, file is generated as root and then it creates issues when you want to commit it, switch branch, etc.

Are we missing something in the way we use this template ?

You can find a solution to this problem (and some other problems) in the file docs/troubleshooting.md.