Attempt to write a readonly database - Django w SELinux error

Question

I have a CentOS server on which I have Apache  Django  Django CMS and mod wsgi   My Django project files are stored in the  srv directory and I have SELinux turned on for security reasons   I ve managed to successfully integrate Django-CMS into Django and when I visit the local IP  I see my pages   However  when I try to visit  admin  where I can start making use of the CMS functionality   I get DatabaseError at  admin  attempt to write a readonly database   Okay   So  since I have a  sqlite file in my project folder  I ran a ls -l on it which returned    -rw-r--r--   1 root root 133120 Jan 5 11 53   DATABASE sqlite   Okay  so I figured perhaps Apache couldn t read that file due to some permissions reasons so after a bunch of research on similar problems on Stackoverflow  I ran     gt  chmod 664 DATABASE sqlite  gt  chown apache  srv mysite  gt  chown apache  srv mysite DATABASE sqlite   Now  the ls -l output reads    -rw-rw-r--   1 apache root 133120 Jan 5 11 53  DATABASE sqlite   Unfortunately  I still get the same error when trying to access  admin on my Django app   Any help would be greatly appreciated   Probably something to do with SELinux permissions but I have no idea where to start in diagnosing what permissions issue is going on   EDIT    I ran    gt  chown apache apache  srv mysite  gt  chown apache apache  srv mysite DATABASE sqlite   and a quick ls -l reveals that the owner of the mysite directory and the  sqlite file is now apache   However  I still get errors when trying to visit the  admin page   I chmoded the  srv mysite directory to 757 and DATABASE sqlite file to 756 because that s the best I can do to get the permissions to work out   I was told that this is a security risk but I can t seem to figure out how to give it less permissions and get pass by unable to read open database file errors   Is it because of SELinux   FYI  I m operating under a regular user account in CentOS and sudo whenever I need to elevate    noblerare localhost

User · Answer

I faced the same problem but on Ubuntu Server. So all I did is changed to superuser before I activate virtual environment for django and then I ran the django server. It worked fine for me.

First copy paste

sudo su

Then activate the virtual environment if you have one.

source myvenv/bin/activate

At last run your django server.

python3 manage.py runserver

Hope, this will help you.

User · Answer

You have to add writing rights to the directory in which your sqlite database is stored  So running chmod 664  srv mysite should help   This is a security risk  so better solution is to change the owner of your database to www-data   chown www-data www-data  srv mysite chown www-data www-data  srv mysite DATABASE sqlite

User · Answer

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    Granting ownership of db sqlite3 file  and its parent directory  thereby write access also  to the user using chown  Eg  chown username db sqlite3   Running the webserver  often gunicorn  as root user  run the command sudo -i before you run gunicorn or django runserver  Allowing read and write access to all users by running command chmod 777 db sqlite3  Dangerous option    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 not recommended  But you can go for it  if you are sure that your application is not vulnerable for code injection attack

User · Answer

I ran into a similar issue  To check if SELinux is the problem  one can check its running status with   sestatus   and temporarily disable it with   setenforce 0   This could at least help to narrow down the problem

User · Answer

This issue is caused by SELinux   After setting file ownership just as you did  I hit this issue   The audit2why 1  tool can be used to diagnose SELinux denials from the log    django  f22-4 www django demo  ftweedal  sudo audit2why -a type AVC msg audit 1437490152 208 407   avc   denied    write         for  pid 20330 comm  httpd  name  db sqlite3  dev  dm-1  ino 52036       scontext system u system r httpd t s0       tcontext unconfined u object r httpd sys content t s0       tclass file permissive 0     Was caused by      The boolean httpd unified was set incorrectly       Description      Allow httpd to unified      Allow access by executing        setsebool -P httpd unified 1   Sure enough  running sudo setsebool -P httpd unified 1 resolved the issue   Looking into what httpd unified is for  I came across a fedora-selinux-list post which explains      This Boolean is off by default  turning it on will allow all httpd   executables to have full access to all content labeled with a http file   context  Leaving it off makes sure that one httpd service can not   interfere with another    So turning on httpd unified lets you circumvent the default behaviour that prevents multiple httpd instances on the same server - all running as user apache - messing with each others  stuff   In my case  I am only running one httpd  so it was fine for me to turn on httpd unified   If you cannot do this  I suppose some more fine-grained labelling is needed

User · Answer

I had this issue and I solved it by creating a directory in mysite folder to hold my db sqlite3 file  so I did  home user src mysite database db sqlite3  In my django setting file I change my  DATABASES      default          ENGINE    django db backends sqlite3        NAME    quot  home user src mysite database db sqlite3 quot        I did this to make Django aware that I am storing my database in a sub directory of the base directory  which mysite in my case  Now you need to grant the permission to apache to be able read write the database  chown user www-data database db sqlite3 chown user www-data database  chmod 755 database  chmod 755 database db sqlite3  This solved my problem  Here is a list of the different permissions  You can use choose the one that fits you but avoid 777 and 666 -rw-------  600  -- Only the user has read and write permissions  -rw-r--r--  644  -- Only user has read and write permissions  the group and others can read only  -rwx------  700  -- Only the user has read  write and execute permissions  -rwxr-xr-x  755  -- The user has read  write and execute permissions  the group and others can only read and execute  -rwx--x--x  711  -- The user has read  write and execute permissions  the group and others can only execute  -rw-rw-rw-  666  -- Everyone can read and write to the file  Bad idea  -rwxrwxrwx  777  -- Everyone can read  write and execute  Another bad idea  Here are a couple common settings for directories  drwx------  700  -- Only the user can read  write in this directory  drwxr-xr-x  755  -- Everyone can read the directory  but its contents can only be changed by the user  here is a link to an article to  learn more  1   1   http   ftp kh edu tw Linux Redhat en 6 2 doc gsg s1-navigating-chmodnum htm    text  2Drwxr 2Dxr 2Dx 20  and 20others 20can 20only 20execute

User · Answer

You can change the owner of your database file and it s folder to django  chown django django  home django mysite chown django django  home django mysite my db sqlite3  This work for DigitalOcean s 1-Click Django Droplet

User · Answer

You can change acls without touching the ownership and permissions of file directory   Use the following commands   setfacl -m u www-data rwx  home user website setfacl -m u www-data rw  home user website db sqlite3

User · Answer

Here my solution   root fiq  home django django project  chmod 777 db sqlite3 root fiq  home django django project  cd    root fiq  home django  chmod 777     Go to  lt  your website admin  gt  put username and password   That s it

[django] Attempt to write a readonly database - Django w/ SELinux error

Examples related to django

Examples related to sqlite

Examples related to selinux