Versuch, eine readonly Datenbank zu schreiben - Django w/SELinux Fehler

Question

Ich habe einen CentOS Server, auf dem ich Apache, Django, Django CMS und mod_wsgi habe. Meine Django-Projektdateien sind im Verzeichnis /srv gespeichert und ich habe SELinux aus Sicherheitsgründen eingeschaltet.

Ich habe es geschafft, Django-CMS erfolgreich in Django zu integrieren und wenn ich die lokale IP besuche, sehe ich meine Seiten. Wenn ich jedoch versuche,/admin zu besuchen (wo ich anfangen kann, die CMS-Funktionalität zu nutzen), bekomme ich DatabaseError at /admin/ attempt to write a readonly database.

Okay.

Also, da ich eine .sqlite Datei in meinem Projektordner haben, lief ich ein ls -l darauf, die zurückgegeben:

-rw-r--r--. 1 root root 133120 Jan 5 11:53 DATABASE.sqlite 

Okay, so dachte ich, vielleicht Apache, dass die Datei nicht aufgrund einiger Berechtigungen lesen konnte Gründe so dass nach einer Reihe von Forschung über ähnliche Probleme auf Stackoverflow, lief ich:

> chmod 664 DATABASE.sqlite 
> chown apache /srv/mysite 
> chown apache /srv/mysite/DATABASE.sqlite 

nun die ls -l Ausgabe lautet:

-rw-rw-r--. 1 apache root 133120 Jan 5 11:53 DATABASE.sqlite 

Leider bekomme ich immer noch den gleichen Fehler beim Zugriff auf/admin auf meiner Django App. Jede Hilfe würde sehr geschätzt werden! Wahrscheinlich etwas mit SELinux-Berechtigungen zu tun, aber ich habe keine Ahnung, wo ich anfangen soll zu diagnostizieren, welche Berechtigungen Problem ist.

EDIT:

lief ich

> chown apache:apache /srv/mysite 
> chown apache:apache /srv/mysite/DATABASE.sqlite 

und eine schnelle ls -l zeigt, dass der Besitzer des mysite Verzeichnis und die Datei .sqlite jetzt apache ist. Allerdings bekomme ich immer noch Fehler beim Versuch, die /admin Seite zu besuchen. Ich chmod Ed die /srv/mysite Verzeichnis zu 757 und DATABASE.sqlite Datei zu 756, weil das ist das Beste, was ich tun kann, um die Berechtigungen zu erarbeiten. Mir wurde gesagt, dass dies ein Sicherheitsrisiko ist, aber ich kann nicht herausfinden, wie es weniger Berechtigungen geben und unable to read/open database file Fehler passieren. Liegt es an SELinux?

FYI, ich bin unter einem normalen Benutzerkonto in CentOS und sudo Betrieb, wenn ich erheben müssen:

[noblerare@localhost ]$ 

Answer 1

Sie müssen Schreibrechte auf das Verzeichnis hinzufügen, in dem Sie Ihre SQLite-Datenbank gespeichert ist. So sollte chmod 664 /srv/mysite laufen helfen.

Dies ist ein Sicherheitsrisiko, ist so eine bessere Lösung, um die Besitzer Ihrer Datenbank www-data zu ändern:

chown www-data:www-data /srv/mysite 
chown www-data:www-data /srv/mysite/DATABASE.sqlite 

Answer 2

ich in ein ähnliches Problem lief.Um zu überprüfen, ob SELinux das Problem ist, kann man seinen laufenden Status überprüfen mit

sestatus 

und vorübergehend deaktivieren mit

setenforce 0 

zumindest helfen Dies könnte das Problem zu verengen.

Answer 3

Dieses Problem wird von SELinux verursacht. Nachdem ich den Dateibesitz so eingerichtet habe, wie du es getan hast, habe ich dieses Problem gefunden. Das audit2why(1) Tool kann verwendet werden SELinux Dementis aus dem Protokoll zu diagnostizieren:

(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 

Sicher genug, läuft sudo setsebool -P httpd_unified 1 das Problem behoben.

in der Suche, was httpd_unified ist, stieß ich auf eine fedora-selinux-list post, die erklärt:

Diese Boolesche standardmäßig ausgeschaltet ist, es dem Einschalten werden alle httpd ausführbaren Dateien erlauben, mit allen Inhalten vollen Zugang zu haben, gekennzeichnet eine HTTP-Datei Kontext. Lassen Sie es aus, stellt sicher, dass ein httpd-Dienst nicht mit einem anderen stören kann.

So httpd_unified Einschalten können Sie das Standardverhalten umgehen, die mehrere httpd Instanzen auf demselben Server verhindert - alle als Benutzer ausgeführt apache - mit jeweils anderen Sachen durcheinander.

In meinem Fall habe ich nur eine httpd, also war es in Ordnung für mich, httpd_unified einzuschalten. Wenn Sie dies nicht tun können, ist vermutlich eine feinkörnigere Beschriftung erforderlich.

Answer 4

Hier ist meine Lösung:

root@fiq:/home/django/django_project# chmod 777 db.sqlite3 
root@fiq:/home/django/django_project# cd .. 
root@fiq:/home/django# chmod 777 * 

Zur <'your_website/admin'> Put-Benutzername und Passwort .. Das ist es.

Answer 5

Kurz gesagt, passiert es, wenn die Anwendung, die in die SQLite-Datenbank schreibt, keine Schreibberechtigung hat.

Dies kann auf drei Arten gelöst werden:

1. von db.sqlite3 Datei und das übergeordnete Verzeichnis (und damit Schreibzugriff auch) an den Benutzer unter Verwendung von chown (zB: chown username db.sqlite3) Gewähren Besitz
2. Lauf der Webserver (oft gunicorn) als Benutzer root (den Befehl sudo -i, bevor Sie gunicorn oder django runserver laufen)
3. Zulassen von Lese- und Schreibzugriff auf alle Benutzer schreiben, indem Befehl ausführen chmod 777 db.sqlite3 (Dangerous Option)

für die dritte Option Gehen Sie nie, wenn Sie den Web-Server in einem lokalen Rechner oder die Daten in der Datenbank ausgeführt wird, überhaupt nicht wichtig für Sie