I'm using django with wsgi on apache2
I was trying to acess a css file in my site/static/css folder and since the permission was 644, the css file could not be accessed by apache2.
So I chmod 645 on the site/static/css folder and everything was fine. However, I am worried that granting execution rights to everyone to anything in the css folder could cause security problems. What is the correct way to tackle this problem, perhaps a way to grant certain permissions using the httpd.conf file?
Thanks!
You can use chown to cause the files to be owned by the same group as apache (www-data?) and then set the permission on the group instead everyone.
Related
I am trying to deploy my Djago app on AWS Lightsail.
When I try to login/register, I am getting this error:
Attempt to write a readonly database
I have been googling solutions for quite some time and have tried setting different permissions, even giving away all permissions which might be huge security risk, however it still doesn't work.
Could anyone help me.
check that your file is owned by bitnami:bitnami. (I've been having the same exact issue and yours and i havent been able to fix it either)
So, in case someone else has this problem, what should work and what worked for me:
I moved db.sqlite3 file to one folder outside of main project dir.
Then I changed address to this file in settings.py to os.path.join(BASE_DIR, '..', 'db.sqlite3')
Though I feel like it's really a problem of user permissions, but that's above my current skill level.
I found another solution that worked for me.
See: https://github.com/mchesler613/django_adventures/blob/main/deploy_django_aws_bitnami.md
Author goes into detail about the details behind the error.
See "Error: Attempt to write a readonly database"
Change group ownership of the project root directory and the database file to daemon. For example:
$ sudo chgrp daemon project_directory project_directory/database_file
Make the project root directory and the database file writable by the daemon group. For example:
$ sudo chmod g+w project_directory project_directory/database_file
To see if the database error goes away, try reloading the Django app on the browser.
I had the same problem. Changing db.sqlite3 mode to writable doesn't work for me. I can use django shell to add data to db.sqlite3 but from apache2, it doesn't work.
Finally, I changed owner of the directory where db.sqlite3 locates to www-data:www-data, and it worked.
I deployed the server with Ubuntu 18, Django, Gunicorn, Nginx
And I ran into this problem:
everything works great but,
When I upload large pictures files in Django, Nginx gives 403 Error Forbidden.
I updated the permissions to the folder with static files on 755. It works!
But when I upload other files, the rights do not work.
I added the user root and user www-data to the folder owner’s group, but nothing has changed.
I understand that Nginx has no permissions, but how can I implement the inheritance permissions of new files from the parent folder
or will you suggest another solution?
You need to add FILE_UPLOAD_PERMISSIONS=0o644 variable to you settings.py file.
This is the numeric mode (i.e. 0o644) to newly uploaded files to.
For more information, please read this doc.
Try use this
chown -R www-data:www-data 'your project folder'
I have read a few interesting articles and watched a few videos but I'm afraid I still have a few things I need help with understanding. I'm a very new dabbler to all this.
1) The example listed in the blog made sense and I tried to implement it but unfortunately my django project is in the home folder and the full wsgi path is /home/serverio/server.io_Tools/server.io/mysite/mysite/wsgi.py. And since www-date needs read and execute permission in order to the open the folders leading up to the last mysite directory, I tried creating a new group which has rwx permission on the static and media folders. This was ok for the static and media folder because I used django collectstatic to move those files into the /var/www folder, which is also has the group that www-data belongs as it's group. The blog did not speak much about situations like mine; where I have wsgi.py in my home folder as shown above. So I tried to make the group of the home folder the same group that www-data belongs(recursively) but the end result was that I could not open the folder from the ubuntu's (GUI) interface even though I also put my username into the same group that is used by www-data and I confirmed that I was also the owner of the directory when I did ls -l. So I abandoned this method and I put www-data in the same group that my userid(the username that was used to build the server) belongs and applied a chmod of 770 to the home folder recursively. With this change, apache was able to open my django app but I really think I may have created a security problem?
2) In the video link, Graham Dumpleton, advised to apply a chmod of 0+rx to the wsgi path which in my case is (/home/serverio/server.io_Tools/server.io/mysite/mysite/). I suspect that means that any web user will now be able to read the files on the computer because Gramham also said people should consider moving django project to a none home location. In this forum, I have seen people moving their project to /var/wwww and I have seen people comment that this is a risk. Gramham also spoke about moving wsgi file ONLY to a new location but I got lost during the explanation.
I suppose my questions are :
a) when a user is browsing a site, what permissions are they using; is it www-data or other (o)? and when we say o+rx are we giving these web users this permission through this command?. Is this enough permission for them to read the raw python code?
b) given my current situation, what's the simplest and effective way forward for me
Thanks forum.
I am using the default logger in Django in models.py like this.
import logging
logging.basicConfig(filename='models.log',level=logging.INFO)
logging.info('Staring execution. Models for db tables')
It is working in the Django server and logs are getting written. When the app is being deployed on Apache, I get a 500 Internal Server error and cannot even load the home page.
The OS is RHEL7. I have changed the file permission of "models.log" to read-write". Still I face the issue. In apache conf file, I have granted permissions as well.
It's problem related with SELinux. If You run locally, then You have full rights to write to log file.
If You run server with apache, then apache must have full rights to write to file.
To check it, login as apache sudo su - apache and try to access to log file.
Solution is simple: put log file in /var/log folder. Or create /var/log/myapp folder and give it full access chmod 777 /var/log/myapp.
import logging
logging.basicConfig(filename='/var/log/myapp/models.log',level=logging.INFO)
logging.info('Staring execution. Models for db tables')
The process needs execute (not only read) access on the directory and parent directories. The best way would be to log in as the user the process is running and try to create the file manually. My guess is you will get a permission error. Create the directories and grant relevant permissions for the directories.
I have a django app containing a model with a file upload field. the upload field takes the targeted file and uploads a copy to either an existing directory in the media root or, if the directory hasn't been created, it creates the directory and drops the file inside of it.
The app works beautifully in dev, utilizing the built-in django server, but when I move it to a production server (my OSX machine running an apache2 instance with mod_wsgi) I get "[Error 13] Permission denied" thrown from the mkdir function in django's storage.py whenever I try to upload a file. I strongly suspect there is permission syntax that needs to be added to my apache httpd.conf. I don't know why else the django server has no trouble with the code but apache gags. Does anyone know?
Permissions issues are described in mod_wsgi documentation at:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
I guess sometimes an error message is exactly what it says it is. In this case "[Error 13] Permission denied" was being thrown because apache didn't have write access to the directories the django app was attempting to upload to. I simply navigated to the the directories I set as file upload directories, and gave write permissions on them systemwide. This probably wasn't the most secure solution, but it was the most practical as, it works and I don't know how to explicitly set write permissions for apache2 without just opening the directory systemwide.
Also, I didn't post the question at serverfault because I didn't know whether it was a django config issue or an apache issue.