При использовании полной аутентификации через SFTP (Вы должны, для учета) затем vsftpd будет использовать полномочия пользователя изменить файлы.
Из-за этого существует два решения:
www-data
или www
)/var/www
, это является намного более мелкомодульным, но раздел должен быть смонтирован с acl
флагЕсли Вы используете анонимный доступ или FTP (который по своей природе небезопасен), я настоятельно рекомендовал бы идти вторым путем.
Сообщение об ошибке говорит само за себя:
/etc/bind/ named.conf. local: 9: open: /var/ named/dnskeys.conf: доступ запрещен
Процесс с именем
обычно работает как пользователь с ограничениями (вероятно, bind
), у которого нет доступа к файлу dnskeys.conf
(с текущими разрешениями доступ к файлу может получить только пользователь root
):
- rw ------- 1 root привязать 126 12 ноября 08:53 dnskeys.conf
Либо измените права для этого файла на 640, чтобы группа bind
имела доступ для чтения,
chmod g+r /var/named/dnskeys.conf
, либо измените владельца файла на пользователя, запустившего именованный
процесс:
chown bind /var/named/dnskeys.conf
Как указывали другие, вам определенно следует НЕ делать файл доступным для чтения всем, а тем более - для записи.
Помимо разрешений на уровне файловой системы, которые вы упомянули выше, вам необходимо настроить привязку, чтобы разрешить эти удаленные обновления с помощью директивы allow-update
.
Мне это кажется проблемой AppArmor. Попробуйте временно установить для него разрешающий режим и посмотрите, исчезнет ли проблема.
По умолчанию демон Bind / Named не имеет разрешения на запись в файлы зоны в / etc. Он может их только читать. Следовательно, процесс nsupdate также не может писать им.
Если вы динамически обновляете свой DNS, вам следует вместо этого хранить файлы зон в / var / lib / bind - https://help.ubuntu.com /14.04/serverguide/dns-configuration.html#dns-primarymaster-configuration
Установщик APT должен был уже создать этот каталог с правильными разрешениями и контекстом AppArmor.