Safe Folder Permissions Structure for Django with mod_wsgi

Using Django Deployment
1

So I asked mod_wsgi dev Graham Dumpleton about a safe Folder Permissions Structure, when running Django+Apache+Linux with mod_wsgi

Here is the discussion on Github: Question: Ideal Secure Folder structure for Django on RedHat or Fedora · Issue #849 · GrahamDumpleton/mod_wsgi · GitHub

I wanted to hear the opinion of people in here, if they had any further feedback upon the issue.

So here is the current plan:

  1. Create a dedicated user (non-admin, normal user) – Question… is that alright ? Being non-admin?

  2. use the ‘user=name’ parameter in Apache config file to define what user the daemon process runs as.

  3. Create the Django project & Python Virtual Environment in /home/NewUser

  4. Minimal .wsgi that loads the application in document root of Apache.

  5. Static/Public files like Favicon, Frontpage html elements to be in document root of apache, and just pointing to it inside Django settings.

2

I haven’t deployed Django under Apache in more than 8 years now, and to be honest, I don’t specifically remember everything. However, I think the analogy is close enough when running Django under nginx / uwsgi that you may find this informative.

  1. Yes, we specifically create non-root, non-system users to run our Django apps, frequently one per project. (I have one server running 5 different projects, each uses their own id.)

  2. We have uwsgi set up to be started as that user.

  3. The virtual environment is created in, and the project is deployed to /home/user.

  4. All static files are deployed to /var/www/html/<project name>/ using collectstatic. The media directories are maintained under /var/media/<project_name>/.

  5. The <project_name> directories are owned by the project, with the group www-data. Only the project can write to those directories. The www-data account can only read them.

Generally, this works for us regardless of whether we’re deploying to bare metal or within Docker containers.

1 Like
3

Yeah, Graham Dumpleton also further replied/clarified about this topic, so I think its a safe direction so far. I am also testing this further, step-by-step… whether I will run into any issues.

I have left SELinux (the topic of my other discussion) for now until the end.

As I mentioned I am doing the tutorial series/walkthrough so that all this research into configuration helps someone down the line. Thanks man, it really helps.

4

I’m trying to deploy my first django project on a digital ocean droplet running ubuntu, nginx and gunicorn. It’s my first time using linux and I’m not sure what (best-practice) privileges the user that runs gunicorn should have. I’m following this guide: How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu | DigitalOcean

I have a user called Leia that can use the sudo command. The django project is stored under /home/Leia/Django_project/. I then use systemd to run gunicorn with my user Leia. Is there any security downside to this? Should I make another user that cannot use sudo to run gunicorn?

What permissions should the user that runs gunicorn have on /home/Leia/Django_project/? You mention that the user should own the project. Does this mean that they should have read, write, execute permissions on all Django_project files or should the permissions be more restrictive?

5

Welcome @LeiasFather !

Yes. The general principle is that accounts should have the fewest permissions necessary to perform their function.

That depends upon what that account needs, where those needs may include factors outside the context of executing your project. (For example, if you do the deployment of the code to that directory using a different account, then the Leia account doesn’t even necessarily need write permissions.)

In other words, you’ll want to look at the overall lifecycle of the project to determine what permissions are required - and what the degree of risk is that you are willing to assume.

Note that you wrote:

That’s not quite an accurate restatement of what I wrote. Quoting in full:

this is a reference back to the previous item:

which is referring to the static and media files, not the project home directory itself.

If you want the most secure environment possible, then no, you don’t want that account having the ability to write to the project files. Whether you need to go that far is a decision that can only be properly made within the context of a full risk assessment.

1 Like