Попытка написать базу данных только для чтения - ошибка Django с SELinux

У меня есть CentOS-сервер, на котором у меня есть Apache, Django, Django CMS и mod_wsgi. Мои файлы проекта 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

Хорошо, поэтому я подумал, что, возможно, Apache не смог прочитать этот файл из-за некоторых разрешений, поэтому после нескольких исследований подобных проблем в Stackoverflow я побежал:

> 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

К сожалению, я все еще получаю ту же ошибку при попытке доступа /admin в моем приложении Django. Любая помощь будет принята с благодарностью! Возможно, что-то связано с разрешениями SELinux, но я не знаю, с чего начать диагностировать, какие проблемы с разрешениями происходят.

EDIT:

Я побежал

> 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?

FYI, я работаю под обычной учетной записью пользователя в CentOS и sudo, когда мне нужно поднять:

[[email protected] ]$

Ответ 1

Вы должны добавить права записи в каталог, в котором хранится ваша база данных sqlite. Поэтому работает chmod 664 /srv/mysite.

Это риск безопасности, поэтому лучшим решением является изменение владельца вашей базы данных на www-data:

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

Ответ 2

Эта проблема вызвана 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, в котором объясняется:

Этот Boolean отключен по умолчанию, включив его, разрешит все httpd исполняемые файлы имеют полный доступ ко всему содержимому, помеченному http файлом контекст. Оставляя это, убедитесь, что одна служба httpd не может мешают другому.

Таким образом, включение httpd_unified позволяет обойти поведение по умолчанию, которое предотвращает несколько экземпляров httpd на одном сервере - все работает как пользователь apache - возится с материалами друг друга.

В моем случае я запускаю только один httpd, поэтому мне было удобно включить httpd_unified. Если вы не можете этого сделать, я полагаю, что требуется более мелкозернистая маркировка.

Ответ 3

У меня возникла аналогичная проблема. Чтобы проверить, является ли проблема SELinux, можно проверить его состояние работы с помощью

sestatus

и временно отключите его с помощью

setenforce 0

Это может по крайней мере помочь сузить проблему.

Ответ 4

Короче говоря, это происходит, когда приложение, которое пишет в базу данных sqlite, не имеет права на запись.

Это можно решить тремя способами:

Предоставление права собственности на файл db.sqlite3 и его родительский каталог (тем самым доступ к записи также) пользователю, использующему chown (например: chown username db.sqlite3)
Запуск веб-сервера (часто пушки) в качестве пользователя root (запустите команду sudo -i перед запуском gunicorn или django runserver)
Разрешить доступ для чтения и записи для всех пользователей, выполнив команду chmod 777 db.sqlite3 (параметр Dangerous)

Никогда не используйте третий вариант, если вы не используете веб-сервер на локальном компьютере, или данные в базе данных не важны для вас.

Ответ 5

Здесь мое решение:

[email protected]:/home/django/django_project# chmod 777 db.sqlite3
[email protected]:/home/django/django_project# cd ..
[email protected]:/home/django# chmod 777 *

Перейдите в <'your_website/admin'>, введите имя пользователя и пароль.. Это.