Вопрос или проблема
Я пытаюсь установить nextcloud на ArchLinuxARM и хотел бы хранить загружаемые данные на NFS-сервере (debian testing). NFS-сервер использует sec=krb5i для экспорта общих ресурсов.
У меня запущен SSSD, и NFS работает без проблем для обычных пользователей.
Тем не менее, мне не удается сделать это для пользователя http.
Я тестирую с помощью
sudo -u http ls /mount/http-folder
Далее, я пытался экспортировать ключи http в keytab-файл, но sudo -u http KRB5_CLIENT_KTNAME=/etc/httpd/conf/krb5.keytab ls /mount/http-folder имеет ту же проблему.
Обновление (2 – решено!):
Приложение должно поддерживать kerberos и учитывать KRB5_CLIENT_KTNAME.
Или лучше, когда клиентский keytab находится в своем месте по умолчанию (как указано Piotr P. Karwasz, который может быть определен с помощью krb5-config --defcktname), он будет подхвачен rpc.gssd автоматически.
[root]> su -l http -s /usr/sbin/bash
[http]> ls /mount/http-folder
ls: cannot open directory '/mount/http-folder': Stale file handle
[http]> krb5-config --defcktname
FILE:/var/lib/krb5/user/%{euid}/client.keytab
[http]> export KRB5_CLIENT_KTNAME=/var/lib/krb5/user/http/client.keytab
[http]> ls /mount/http-folder
ls: cannot access '/mount/http-folder': Permission denied
# обратите внимание на разницу (1)
[http]> $ kinit -t $KRB5_CLIENT_KTNAME http
keytab specified, forcing -k
[http]> ls /mount/http-folder
this_is_www-data
[http]> exit
# решение:
[root]> mv /var/lib/krb5/user/http /var/lib/krb5/user/`id -u http`
[root]> su -l http -s /usr/sbin/bash
[http]> kdestroy # (2)
[http]> ls /mount/http-folder
this_is_www-data
(1) не уверен, что вызывает это – согласно документации kerberos он должен использовать первый principal, который найдет в файле клиентского keytab – клиентский keytab содержит только желаемый principal, так что … ? Как правильно заметил Piotr P. Karwasz, %{euid] – это цифровой идентификатор, а не имя пользователя (упс!), так что клиентский keytab не находится в месте по умолчанию!
(2) убедитесь, что кэш билетов пустой
Итак, проблема решена. Спасибо, Петр!
Когда процесс получает доступ к вашему NFS-монтажу, ядро вызывает rpc.gssd для установления учетных данных. Я не исследовал механизм вызова более подробно, но я считаю, что rpc.gssd не имеет доступа к переменной KRB5_CLIENT_KTNAME или просто игнорирует ее и использует местоположение по умолчанию.
Файл /var/lib/krb5/user/http/client.keytab не является местоположением по умолчанию в вашей системе. Попробуйте заменить http на числовой uid пользователя http:
getent passwd http | cut -d : -f 3
Ответ или решение
Настройка Nextcloud на ArchLinuxARM с использованием NFS-сервера на Debian, который требует аутентификации Kerberos с параметром sec=krb5i, может быть вызовом, особенно если требуется интеграция с системой безопасности и доступ для определенных пользователей, таких как пользователь http. Весь процесс требует понимания работы Kerberos и взаимодействия с NFS, а также настройки учетных данных и доступа для конкретного пользователя.
Теоретическая часть (Theory)
NFS с параметром sec=krb5i обеспечивает аутентифицированный доступ с использованием Kerberos с проверкой целостности данных. Это усложняет конфигурацию, но повышает уровень безопасности, защищая данные от несанкционированного доступа и изменения. В этом контексте необходимо, чтобы все клиенты NFS, включая процессы, работающие от имени пользователя http, корректно аутентифицировались через Kerberos.
Kerberos – это протокол сетевой аутентификации, использующий ключи шифрования для обеспечения безопасности идентификации пользователей и услуг. В контексте NFS это значит, что каждый пользователь или процесс, который хочет получить доступ к файлам на сервере NFS, должен иметь действительный билет Kerberos.
Для возможности безболезненной работы с NFS, сервер должен доверять предоставленному билету, и клиент (в данном случае процесс от пользователя http) должен иметь доступ к клиентскому keytab-файлу, в котором хранится секретная информация для получения таких билетов.
Пример (Example)
Как выяснилось из описания проблемы, основной трудностью была надлежащая аутентификация пользователя http через Kerberos. Библиотека SSSD (System Security Services Daemon) была уже установлена и работала для обычных пользователей, но для пользователя HTTP наблюдались проблемы.
Первоначально была предпринята попытка указать свой keytab-файл через переменную окружения KRB5_CLIENT_KTNAME, однако система не принимала его, что, как было выяснено, связано с тем, что rpc.gssd, демон клиента Kerberos для NFS, не учитывает эту переменную и использует ключи из своего стандартного местоположения.
Применение (Application)
Для решения проблемы необходимо было убедиться, что клиентский keytab-файл располагался в правильной директории, откуда rpc.gssd смог бы его автоматически подобрать. На практике это значит:
-
Проверка стандартного местоположения ключевого файла: Как было обнаружено, выполнение команды
krb5-config --defcktnameдля определения стандартного пути к клиентскому keytab-файлу показало, что файл должен быть по пути/var/lib/krb5/user/[UID]/client.keytab, где[UID]заменяется на UID пользователя. -
Перемещение и переименование keytab-файла: Основное решение состояло в перемещении директории из
/var/lib/krb5/user/httpв новую директорию/var/lib/krb5/user/[UID_пользователя_http], чтобы она соответствовала стандартному местоположению. -
Очистка кэша билетов: Еще один важный шаг – освободить предыдущие билеты Kerberos, используя команду
kdestroy, для удостоверенности в том, что демоны или другие процессы не используют устаревшие или неправильные билеты.
Проведение этих действий позволило корректно настроить окружение для пользователя HTTP и использовать NFS с параметром sec=krb5i, решив проблему "Stale file handle" и "Permission denied".
Эти действия демонстрируют, как важен учет всех деталей, когда необходимо адаптировать конфигурации для интеграции и работы в безопасной компьютерной среде. Своевременное применение правильных настроек и понимание того, как взаимодействуют различные компоненты системы, являются ключом к успешной реализации проектов в IT-инфраструктуре.