9

I have just created a Django project with

python manage.py startapp smartrecruitment

I then ran a db sync

 python manage.py syncdb
 Operations to perform:
 Apply all migrations: admin, contenttypes, auth, sessions
 Running migrations:
   Applying contenttypes.0001_initial... OK
   Applying auth.0001_initial... OK
   Applying admin.0001_initial... OK
   Applying sessions.0001_initial... OK

And added my superuser, but I cannot access /admin in the browser. I have tried doing the following commands to give apache permissions, but have had no luck.

sudo chown apache <folder_containing_db.sqlite3>
sudo chown apache db.sqlite3
ruddra
  • 50,746
  • 7
  • 78
  • 101
Jon
  • 3,174
  • 11
  • 39
  • 57
  • Why are you running your project with Apache when it's in development? Use the dev server, it's easier. – Daniel Roseman Oct 13 '14 at 08:25
  • It's not, but I was having trouble with Django 1.7, so wanted to simply get a basic project deployed on my server. – Jon Oct 13 '14 at 08:27
  • @Jon What makes you say the database is "read-only"? "I cannot access /admin in the browser" is vague. Cannot access how? Get an error in the browser? Get an error in the Apache logs? Some other error? – Louis Oct 13 '14 at 10:52
  • I get the error "Attempt to write a read-only database" when I go to that URL. It should be coming up with a login form for the admin section, but all I get is an error page with that message displayed. It is very similar to this issue... http://stackoverflow.com/questions/21054245/attempt-to-write-a-readonly-database-django-w-selinux-error – Jon Oct 13 '14 at 11:08
  • how is it different from [the quesiton you've linked](http://stackoverflow.com/questions/21054245/attempt-to-write-a-readonly-database-django-w-selinux-error)? – jfs May 17 '15 at 13:49

4 Answers4

19

change owner of the project directory and database file www-data

chown www-data:www-data /home/username/Django    
chown www-data:www-data /home/username/Django/db.sqlite  
simeg
  • 1,889
  • 2
  • 26
  • 34
vishal
  • 301
  • 2
  • 4
  • I don't know why someone downvoted it. This answer actually helped me! – xyres Aug 17 '15 at 14:27
  • 2
    This is not a good practice. Your `www-data` user has write permissions on your db (and needs to) so it works, but you also gave it write permissions to your entire codebase, which it definitely should not be able to do – Thibaut Aug 31 '18 at 10:11
4

You have indeed user/group permission problems : you need to run your webserver with a user who has read / write access to your db file (when using sqlite3)

Changing the owner and the group of your entire project is a bad idea since it would allow your web server user to write on your codebase, which is never a good practice.

A better idea is to use a real database in production instead of sqlite to avoid this.

https://docs.djangoproject.com/en/1.9/ref/settings/#databases

If you want to stick with sqlite : place your sqlite file outside of your project repository and give it and the containing directory correct read/write accesses (for instance only www-data can write, but then you need to run your django commands as www-data)

some_dir [your_user:your_group]
--- your_django_project [github_user:github_user]
--- another_dir [www-data:www-data]
    |--- db.sqlite3 [www-data:www-data]

And your webserver (apache / nginx ) runs as www-data

Thibaut
  • 133
  • 1
  • 10
  • can you please add some sample code here? this is more a theoretical answer which does not completely solve the issue. it already sounds right but it qould be perfect if you add some code too! Thanks! – cramopy Mar 28 '16 at 10:43
  • I've edited my response, there is no code involved since it's just permissions – Thibaut Mar 28 '16 at 12:37
1

I was looking for the solution, as I followed CentOS tutorial by this link. https://www.digitalocean.com/community/tutorials/how-to-serve-django-applications-with-apache-and-mod_wsgi-on-centos-7

Here is the permission for that tutorial,

sudo usermod -a -G root apache
chmod 710 /root/myproject
chown apache:apache /root/myproject
chown apache:apache /root/myproject/db.sqlite
Aman Juman
  • 404
  • 5
  • 12
0

In short, it happens when the application which writes to the sqlite database does not have write permission.

This can be solved in three ways:

  1. Granting ownership of db.sqlite3 file and its parent directory (thereby write access also) to the user using chown (Eg: chown username db.sqlite3 )
  2. Running the webserver (often gunicorn) as root user (run the command sudo -i before you run gunicorn or django runserver)
  3. Allowing read and write access to all users by running command chmod 777 db.sqlite3 (Dangerous option)

Note: Never go for the third option unless you are running the webserver in a local machine or the data in the database is not at all important for you.

Second option is also dangerous as @mateuszb said. Risk of code injection is very low in Django since Django is designed in such a way. In Django, capture of entire OS can happen only if the developer writes horribly vulnerable code using eval or exec. If you are not confident about your code quality or even don't know what code injection is, second option is not for you.

Moreover, this error does not occur if you are using a database like mysql and Postgres. Sqlite is not a good option for a webserver with a high traffic.

Mohammed Shareef C
  • 3,829
  • 25
  • 35
  • Never do 2 either. Any gap in your code gives sudo rights to the hacker. – mateuszb Mar 26 '18 at 01:34
  • @mateuszb I agree. Can you give a typical example? – Mohammed Shareef C Mar 26 '18 at 13:38
  • I am not sure what would a typical one be, but any code injection could lead to the capture of entire operating system, putting at risk the internal network. If the website belongs to apache (as in the case of apache httpd) then the hacker is limited only to the files it owns and can write to - which should exclude even its own code. Limited tools should also be available to such a user (no ssh etc). – mateuszb Mar 27 '18 at 12:22
  • @mateuszb Risk of code injection is very low in Django since django is designed in such a way. In Django, capture of entire OS can happen only if the developer writes horribly vulnerable code using `eval` or `exec` – Mohammed Shareef C Sep 07 '18 at 05:09