Monday, February 14, 2022

Re: collectstatic files chown'ed by root

Everything works fine except for the collectstatic command (in entrypoint.sh), which creates the "staticfiles" directory but it's owned by root.
This is not possible. If "manage.py" is running as a non-root user, it wouldn't be possible for it to create a directory owned by root. Something else is going on. Could you share your entrypoint.sh script?

Antonis Christofides  +30-6979924665 (mobile)

On 14/02/2022 13.14, 'Tim' via Django users wrote:
Hi all,
I'm deploying Django 4 via docker-compose. For security reasons, the Dockerfile creates a non-root user before running the entrypoint.sh script (which does migrations, collectstatic and starts the server with gunicorn). All app files are "chown"ed by this non-root user.

Everything works fine except for the collectstatic command (in entrypoint.sh), which creates the "staticfiles" directory but it's owned by root. This leads to permission denied errors when the collectstatic command tries to delete a static file.

My question: Why does collectstatic assign the folder to "root" despite the non-root user calling the collectstatic command? How to prevent this?

I tried doing the collectstatic command before switching to the non-root user (in the Dockerfile) which works. But it stops working when I put the Django SECRET_KEY in a .env file (as we should in production) since this env var is not available during docker build time.

Now I could find a hackier way by making the secret key available during build time or switching back to a root user in entrypoint.sh, but all of this is a bad workaround in my opinion.

I'm sure everyone deploying Django with docker and being mindful of security has come across this - Any hints about why collectstatic is owned by root? Is this a bug?

Should I add additional details?

Thanks for any tips!
Tim
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c3381f62-4bf1-4142-b27f-189ef45a75fan%40googlegroups.com.

No comments:

Post a Comment