By mpasquali
I’ve been researching permissions for Django directories and files on my Droplet. I’ve asked a few questions on DO Community regarding this and have had excellent advice. However, I am continuing this question because I’m finding out a few things:
In checking the Droplet, I have ownership of files set to a specific user I elevate privileges to perform certain ops. I set this up according to the following link:
https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-20-04
Therefore, I do not have ownership of files set to root. Ownership of files is set to that particular user.
In checking the following reply to question on the following link, it states:
“All files and directories in our production environment are owned by root:root with 755/644 file permissions, unless otherwise required.”
But it also states “Our nginx process runs as www-data. In general each Django project has its own user, and the gunicorn process runs as this user.”
So, my Django project is owned by my specified user, not the root. Therefore, all the directories and files are owned by this user. My main question is: Should they be all be owned by root instead??
I’ve have this setup on my Dev Server at my office with a specified user, not root. It works, but when I changed permissions to 755 for Directories and 644 for Files for my Django project and apps, the virtual environment directory and files were changed as well. I was subsequently not able to execute the pip command from within PyCharm IDE. I had to raise permissions on pip in order to do so. Question: Should I leave the virtual environment permissions “as is,” especially the files in the bin directory.
Any help would be greatly appreciated. Basically, I want to ensure I have a secure environment in Production without having issues with running my apps.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Heya,
Ownership of files and directories by a specific non-root user is a commonly used security practice on Linux-based systems. This approach helps to minimize any potential damage that could be caused by vulnerabilities in the web server or the application it’s serving.
In your case, your Django application and related files should largely be owned by the specific user used for the operations of your application, not root. This includes the Django project files, applications, and the virtual environment. This measure ensures these files are not unnecessarily exposed with elevated permissions. Adhering strictly to this principle will allow for more granular control and better security over who and what processes can modify your application files.
However, your server’s configuration should allow the www-data user read and execute permissions (such as 755 for directories and 644 for files) since this is the user Nginx runs under.
The pip command issue you faced in the PyCharm IDE is likely due to the change in permissions. You may want to revert those changes for any files/directories affecting the pip command while maintaining security best practices. One way to do this could be to ensure the user you’re running PyCharm as is also part of the same group that owns these files/directories.
For your reference, here’s a link to DigitalOcean’s guide on setting up Django with Postgres, Nginx, and Gunicorn on Ubuntu 22.04. It should provide a good understanding of how these various components interact and their permissions.
Daily operations, security, and maintenance of a server involves a delicate balance, and it can be a bit of a learning curve.
Hope that this helps!
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and AI-native businesses
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Start building today
From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.
