web-dev-qa-db-ja.com

読み取り専用データベースに書き込もうとしています-Django w / SELinuxエラー

Apache、Django、Django CMSおよびmod_wsgiがインストールされているCentOSサーバーがあります。 Djangoプロジェクトファイルは/srvディレクトリに保存されており、セキュリティ上の理由からSELinuxを有効にしています。

Django-CMSをDjangoに正常に統合できました。ローカルIPにアクセスすると、ページが表示されます。ただし、/ admin（CMS機能の使用を開始できる場所）にアクセスしようとすると、DatabaseError at /admin/ attempt to write a readonly databaseが返されます。

はい。

そのため、プロジェクトフォルダーに.sqliteファイルがあるため、その上でls -lを実行し、次の結果を返しました。

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

OK

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

これで、ls -l出力は次のようになります。

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

残念ながら、Djangoアプリで/ adminにアクセスしようとすると、同じエラーが表示されます。どんな助けも大歓迎です！おそらくSELinuxのパーミッションと関係があるかもしれませんが、どのパーミッションの問題が起こっているかを診断するためにどこから始めればいいのか分かりません。

編集：

走った

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

ls -lをすばやく確認すると、mysiteディレクトリと.sqliteファイルの所有者がApacheになっていることがわかります。ただし、/adminページにアクセスしようとするとエラーが発生します。 chmodを/srv/mysiteディレクトリに757し、DATABASE.sqliteファイルを756にしたのは、許可を得るためにできる最善の方法だからです。これはセキュリティ上のリスクであると言われましたが、許可を減らしてunable to read/open database fileエラーを回避する方法を理解できないようです。 SELinuxが原因ですか？

参考までに、私はCentOSとSudoの通常のユーザーアカウントで、昇格する必要があるたびに操作しています。

[noblerare@localhost ]$
djangosqliteselinux
43
noblerare

Sqliteデータベースが保存されているディレクトリに書き込み権限を追加する必要があります。したがって、chmod 664 /srv/mysiteを実行すると役立ちます。

これはセキュリティ上のリスクであるため、データベースの所有者をwww-dataに変更することをお勧めします。

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

この問題は、SELinuxが原因です。あなたがしたようにファイルの所有権を設定した後、私はこの問題にぶつかりました。 audit2why(1)ツールを使用して、ログからSELinux拒否を診断できます。

(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

案の定、Sudo setsebool -P httpd_unified 1を実行することで問題は解決しました。

httpd_unifiedの目的を調べたところ、 Fedora-selinux-list post に出会いました。

このブール値はデフォルトでオフになっています。オンにすると、すべてのhttpd実行可能ファイルが、httpファイルコンテキストでラベル付けされたすべてのコンテンツにフルアクセスできるようになります。無効にすると、あるhttpdサービスが別のhttpdサービスに干渉することがなくなります。

したがって、httpd_unifiedをオンにすると、同じサーバー上で複数のhttpdインスタンス（すべてユーザーApacheとして実行されている）が互いに干渉するのを防ぐデフォルトの動作を回避できます。

私の場合、実行しているhttpdは1つだけなので、httpd_unifiedをオンにすることは問題ありませんでした。これができない場合、さらに細かいラベル付けが必要だと思います。

7
frasertweedale

つまり、sqliteデータベースに書き込むアプリケーションに書き込み権限がない場合に発生します。

これは3つの方法で解決できます。

  1. db.sqlite3ファイルとその親ディレクトリの所有権を付与する（それにより書き込みアクセスも）chownを使用してユーザーに付与する（例：chown username db.sqlite3）
  2. Webサーバー（多くの場合gunicorn）をrootユーザーとして実行します（gunicornまたはDjango runserverを実行する前にコマンドSudo -iを実行します）
  3. コマンドchmod 777 db.sqlite3（危険なオプション）を実行して、すべてのユーザーに読み取りおよび書き込みアクセスを許可します

ローカルマシンでWebサーバーを実行している場合、またはデータベースのデータがまったく重要でない場合を除き、3番目のオプションを選択しないでください。

2番目のオプションも推奨されません。しかし、アプリケーションがコードインジェクション攻撃に対して脆弱でないと確信している場合は、それを試すことができます。

4
Mohammed Shareef C

私は同様の問題に遭遇しました。 SELinuxに問題があるかどうかを確認するには、次のコマンドで実行ステータスを確認できます。

sestatus

一時的に無効にします

setenforce 0

これにより、少なくとも問題を絞り込むことができます。

1
bdoering

ファイル/ディレクトリの所有権とアクセス権を変更せずに、acl sを変更できます。

次のコマンドを使用します。

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