vsftpd: 500 OOPS: сбой prctl PR_SET_SECCOMP

Question

У меня проблема с vsftpd . Когда я подключаюсь к своему FTP-серверу через FileZilla, я получаю сообщение об ошибке:

500 OOPS: prctl PR_SET_SECCOMP не удалось
Ошибка: критическая ошибка
Ошибка: не удалось подключиться к серверу

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

Я запускаю Ubuntu 14.04 на VPSDime VPS. vsftpd версия 3.0.2 . Ошибка не произошла после обновления или изменения конфигурации, но ошибка начала возникать, когда я работал на веб-сайте; до того как я получил ошибку, все работало нормально.

Я перезагрузил, перезапустил vsftpd и обновил мою систему. Есть идеи?

Answer 1

Сообщение указывает на сбой вызова prctl(PR_SET_SECCOMP, ...) .

ret = prctl(PR_SET_SECCOMP, 2, &prog, 0, 0);
if (ret != 0)
{
  die("prctl PR_SET_SECCOMP failed");
}

Это может произойти, если в вашем ядре не включена CONFIG_SECCOMP_FILTER . Но это вряд ли изменится, пока вы "работаете над сайтом".

Цитата из справочной страницы prctl:

PR_SET_SECCOMP (начиная с Linux 2.6.23)

Установите режим защищенных вычислений (seccomp) для вызывающего потока, чтобы ограничить доступные системные вызовы. Режим seccomp выбирается через arg2 . (Константы seccomp определены в <linux/seccomp.h>

...

Если для arg2 установлено значение SECCOMP_MODE_FILTER (начиная с Linux 3.5), разрешенные системные вызовы определяются указателем на пакетный фильтр Berkeley, передаваемый в arg3. Этот аргумент является указателем на struct sock_fprog ; он может быть разработан для фильтрации произвольных системных вызовов и аргументов системных вызовов. Этот режим доступен, только если ядро настроено с включенным CONFIG_SECCOMP_FILTER .

---

В качестве плохого решения вы можете настроить vsftpd так, чтобы он не включал режим seccomp.

Используйте параметр seccomp_sandbox=no в vsftpd.conf .

Опция, кажется, не документирована.

Answer 2

Response:    500 OOPS: vsftpd: refusing to run with writable root inside chroot()

Ошибка "500 OOPS", возвращаемая vsftpd, является мерой безопасности, разработанной для предотвращения доступного для записи корневого доступа для пользователей FTP по умолчанию. Для решения этой проблемы есть два основных варианта.

Разрешение доступного для записи доступа пользователя-root

Самый простой способ - еще раз изменить файл /etc/vsftpd.conf и включить один конкретный параметр:

nano /etc/vsftpd.conf

Отредактируйте файл так, чтобы он выглядел следующим образом:

# Allow users to write to their root directory
allow_writeable_chroot=YES

https://uk.godaddy.com/help/how-to-set-up-an-ftp-server-on-ubuntu-1404-12301

Answer 3

Причиной, по которой эта ошибка из vfstpd возникает в некоторых ядрах Linux (особенно в RHEL/Centos 6.x начиная с версии 6.5), является следующее предположение в источниках vsftpd:

https://github.com/dagwieers/vsftpd/blob/master/seccompsandbox.c#L642

  ret = prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
  if (ret != 0)
  {
    if (errno == EINVAL)
    {
      /* Kernel isn't good enough. */
      return;
    }
    die("prctl PR_SET_NO_NEW_PRIVS");
  }

  if (!tunable_seccomp_sandbox)
  {
    return;
  }
[ ... ]
  ret = prctl(PR_SET_SECCOMP, 2, &prog, 0, 0);
  if (ret != 0)
  {
    die("prctl PR_SET_SECCOMP failed");
}

С помощью https://rhn.redhat.com/errata/RHSA-2015-0864.html Redhat добавлено:

Примечание: исправление для этой проблемы является частью ядра общего исправления и представляет функциональность PR_SET_NO_NEW_PRIVS и соответствующую поддержку переходов SELinux exec.

Это нарушает предположение vsftpd выше, что любое ядро, которое поддерживает PR_SET_NO_NEW_PRIVS также поддерживает режим 2 PR_SET_SECCOMP .

vsftpd молча игнорирует EINVAL из первого prctl(), но завершается неудачно с отображаемым сообщением об ошибке во втором.

Упомянутый выше параметр конфигурации Martin Prikryl просто заставляет его корректно завершить работу сразу после (теперь уже успешно) первого prctl (), в то время как до / на старых ядрах он чисто / тихо завершал работу при этом вызове.