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

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

J'ai réussi à intégrer avec succès Django-CMS dans Django et lorsque je visite L'IP locale, je vois mes pages. Cependant, quand j'essaie de visiter / admin (où je peux commencer à faire usage de la fonctionnalité CMS), j'obtiens DatabaseError at /admin/ attempt to write a readonly database.

Ok.

donc, puisque je avoir un .sqlite le fichier dans mon dossier de projet, j'ai couru un ls -l, qui est retourné: 

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

Ok, donc J'ai pensé Qu'Apache ne pourrait peut-être pas lire ce fichier à cause de certaines permissions, donc après un tas de recherches sur des problèmes similaires sur Stackoverflow, j'ai couru: 

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

Maintenant,ls -l sortie se lit comme suit: 

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

malheureusement, j'obtiens toujours la même erreur en essayant d'accéder /admin sur mon application Django. Toute aide serait grandement appréciée! Probablement quelque chose à voir avec les permissions SELinux mais je n'ai aucune idée où commencer à diagnostiquer ce problème de permissions est en cours.

EDIT:

j'ai couru 

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

rapide ls -l révèle que le propriétaire du mysite répertoire .sqlite le fichier est maintenant apache. Cependant, j'obtiens toujours des erreurs quand j'essaye de visiter le /admin page. J' chmoded /srv/mysite répertoire de 757 et DATABASE.sqlite file à 756 parce que c'est le mieux que je puisse faire pour obtenir les autorisations de travail. On m'a dit que c'était un risque de sécurité, mais je n'arrive pas à trouver comment lui donner moins de permissions et passer par unable to read/open database file erreurs. Est-ce à cause de SELinux?

pour info, je travaille sur un compte d'Utilisateur régulier à CentOS et sudo chaque fois que j'ai besoin d'élever:

[noblerare@localhost ]$
38
demandé sur noblerare 2014-01-11 00:55:52

5 réponses

vous devez ajouter des droits d'écriture au répertoire dans lequel votre base de données sqlite est stockée. Ainsi de courir chmod 664 /srv/mysite devrait aider.

il s'agit d'un risque de sécurité, donc la meilleure solution est de changer le propriétaire de votre base de données à www-data:

chown www-data:www-data /srv/mysite
chown www-data:www-data /srv/mysite/DATABASE.sqlite
49
répondu niekas 2014-01-11 10:29:16

ce problème est causé par SELinux. Après avoir défini la propriété des fichiers comme vous l'avez fait, j'ai trouvé ce numéro. audit2why(1) outil peut être utilisé pour diagnostiquer les refus SELinux à partir du 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

bien Sûr, running sudo setsebool -P httpd_unified 1 résolu le problème.

à la recherche de quoi httpd_unified est, je suis tombé sur un fedora-selinux-list post ce qui explique:

ce booléen est désactivé par défaut, l'activer permettra à tous les httpd les exécutables pour avoir un accès complet à tout le contenu étiqueté avec un fichier http cadre. Quitter hors assure un service httpd peut pas d'interférer avec un autre.

Donc tourner sur httpd_unified permet de contourner le comportement par défaut qui empêche plusieurs httpd instances sur le même serveur - tous en cours d'exécution en tant qu'utilisateur apache - jouer avec les affaires de l'autre.

Dans mon cas, je suis seulement en cours d'exécution httpd, donc c'était bon pour moi de tourner sur httpd_unified. Si vous ne pouvez pas faire ceci, je suppose qu'un étiquetage plus fin est nécessaire.

7
répondu frasertweedale 2015-07-21 15:07:41

en bref, cela arrive quand l'application qui écrit dans la base de données sqlite n'a pas la permission d'écrire.

ceci peut être résolu de trois façons:

  1. according ownership of db.sqlite3 le fichier et son répertoire parent (écrivent ainsi l'accès aussi) à l'utilisateur en utilisant chown (par exemple:chown username db.sqlite3)
  2. exécuter le serveur web (souvent gunicorn) comme utilisateur root (exécuter la commande sudo -i avant d'exécuter gunicorn ou django runserver)
  3. permettant l'accès en lecture et en écriture à tous les utilisateurs en exécutant la commande chmod 777 db.sqlite3 (option Dangereuse)

N'optez jamais pour la troisième option sauf si vous utilisez le serveur web dans une machine locale ou si les données de la base de données ne sont pas importantes pour vous.

Deuxième option n'est pas recommandée. Mais vous pouvez aller pour elle, si vous êtes sûr que votre application n'est pas vulnérable pour l'injection de code d'attaque.

3
répondu Mohammed Shareef C 2018-05-03 08:33:24

j'ai rencontré un problème similaire. Pour vérifier si SELinux est le problème, on peut vérifier son état d'exécution avec 

sestatus

et le désactiver temporairement avec 

setenforce 0
1
répondu bdoering 2014-11-15 22:00:47

Ici ma solution:

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

<'your_website/admin'> mettez nom d'utilisateur et mot de passe.. C'est tout.

-5
répondu saffiq 2017-03-21 17:40:12