web-dev-qa-db-fra.com

Essayez d’écrire une base de données en lecture seule - Django w / erreur SELinux

J'ai un serveur CentOS sur lequel j'ai Apache, Django, Django CMS et mod_wsgi. Mes fichiers Django sont stockés dans le répertoire /srv répertoire et j’ai activé SELinux pour des raisons de sécurité.

J'ai réussi à intégrer Django-CMS dans Django et lorsque je visite l'adresse IP locale, je vois mes pages. Cependant, lorsque j'essaie de visiter/admin (où je peux commencer à utiliser de la fonctionnalité CMS), je reçois DatabaseError at /admin/ attempt to write a readonly database.

D'accord.

Donc, puisque j'ai un fichier .sqlite Dans mon dossier de projet, j'ai exécuté un ls -l Dessus, qui a retourné:

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

D'accord, j'ai donc pensé qu'Apache ne pouvait peut-être pas lire ce fichier pour des raisons d'autorisations. Après de nombreuses recherches sur des problèmes similaires sur Stackoverflow, j'ai lancé:

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

Maintenant, la sortie ls -l Lit:

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

Malheureusement, j'obtiens toujours la même erreur lorsque j'essaie d'accéder à/admin sur mon Django. Toute aide serait grandement appréciée! Probablement quelque chose à voir avec les autorisations SELinux mais je ne sais pas par où commencer. pour diagnostiquer quel problème d'autorisations se produit.

EDIT:

Iran

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

et un rapide ls -l révèle que le propriétaire du répertoire mysite et du fichier .sqlite est maintenant Apache. Cependant, des erreurs persistent lorsque j'essaie de visiter la page /admin. J'ai chmoded le répertoire /srv/mysite À 757 et le fichier DATABASE.sqlite À 756 car c'est le mieux que je puisse faire pour obtenir les autorisations nécessaires. On m'a dit qu'il s'agissait d'un risque pour la sécurité, mais je n'arrive pas à comprendre comment lui donner moins d'autorisations et obtenir des erreurs unable to read/open database file. Est-ce à cause de SELinux?

Pour votre information, je suis sous un compte utilisateur régulier dans CentOS et Sudo chaque fois que je dois élever:

[noblerare@localhost ]$
djangosqliteselinux
43
noblerare

Vous devez ajouter des droits en écriture sur le répertoire dans lequel votre base de données sqlite est stockée. Donc, courir chmod 664 /srv/mysite devrait aider.

Ceci est un risque pour la sécurité, donc la meilleure solution consiste à changer le propriétaire de votre base de données en www-data:

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

Ce problème est causé par SELinux. Après avoir défini la propriété du fichier comme vous l'avez fait, j'ai résolu ce problème. L'outil audit2why(1) peut être utilisé pour diagnostiquer les refus de SELinux à partir du journal:

(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

Effectivement, en cours d'exécution Sudo setsebool -P httpd_unified 1 résolu le problème.

Regarder dans quoi httpd_unified est pour, je suis tombé sur un message de Fedora-selinux-list qui explique:

Ce booléen étant désactivé par défaut, son activation permettra à tous les exécutables httpd d'avoir un accès complet à tout le contenu étiqueté avec un contexte de fichier http. En le désactivant, un service httpd ne peut en interférer avec un autre.

Donc, allumer httpd_unified vous permet de contourner le comportement par défaut qui empêche plusieurs instances httpd sur le même serveur - s'exécutant toutes en tant qu'utilisateur Apache - de se mêler des affaires des autres.

Dans mon cas, je n’utilise qu’un httpd, donc c’était bien pour moi d’allumer httpd_unified. Si vous ne pouvez pas faire cela, je suppose qu’un étiquetage plus fin est nécessaire.

7
frasertweedale

En bref, cela se produit lorsque l’application qui écrit dans la base de données sqlite n’est pas autorisée en écriture.

Cela peut être résolu de trois manières:

  1. Accorder la propriété de db.sqlite3 fichier et son répertoire parent (donnant ainsi également un accès en écriture) à l’utilisateur utilisant chown (exemple: chown username db.sqlite3)
  2. Exécution du serveur Web (souvent gunicorn) en tant qu’utilisateur root (exécutez la commande Sudo -i avant de lancer gunicorn ou Django runserver)
  3. Autorisation d'accès en lecture et en écriture à tous les utilisateurs en exécutant la commande chmod 777 db.sqlite3 _ (Option dangereuse)

Ne choisissez jamais la troisième option, sauf si vous exécutez le serveur Web sur une machine locale ou que les données de la base de données ne sont pas du tout importantes pour vous.

La deuxième option n'est également pas recommandée. Mais vous pouvez y aller, si vous êtes sûr que votre application n'est pas vulnérable aux attaques par injection de code.

4
Mohammed Shareef C

J'ai rencontré un problème similaire. Pour vérifier si SELinux est le problème, on peut vérifier son état de fonctionnement avec

sestatus

et le désactiver temporairement avec

setenforce 0

Cela pourrait au moins aider à réduire le problème.

1
bdoering

Vous pouvez modifier acl s sans toucher à la propriété et aux autorisations du fichier/répertoire.

Utilisez les commandes suivantes:

setfacl -m u:www-data:rwx /home/user/website
setfacl -m u:www-data:rw /home/user/website/db.sqlite3
0
Mohammad Etemaddar