Назад | Перейти на главную страницу

Разрешения не вступают в силу с Kerberised NFSv4 на FreeBSD

В настоящее время я пытаюсь настроить сервер NFSv4 на FreeBSD. У меня большой опыт работы с другими Unix (Solaris и Linux), но я новичок во FreeBSD.

Моя цель - добиться следующего:

В настоящее время мне удалось настроить все так, что мне нужен действующий TGT для доступа к файловой системе. После попытки получить доступ к этим файлам я могу запустить klist на клиенте, и я вижу, что nfs/domainname принципал был получен. Это говорит о том, что часть Kerberos монтирования NFS верна.

Моя проблема в том, что все обращения клиентов по-прежнему выполняются с использованием nobody пользователь. Я вижу разрешения, когда делаю это ls -l. Даже отображение пользователя работает правильно, но если nobody имеет разрешение делать что-либо с файлами, мне отказано в разрешении.

Вот пример взаимодействия со стороны клиента (в данном случае Ubuntu, но то же самое происходит с OSX). В этом примере /export/shared/testshare это общий каталог с сервера FreeBSD:

(Я изменил фактическое доменное имя на domain и имя области Kerberos для REALM)

$ kinit
Password for elias@REALM:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
$ sudo mount -t nfs4 -osec=krb5p,vers=4 lion:/export/shared/testshare /mnt
$ ls -l /mnt
total 4
-rw-r--r-- 1 nobody nogroup   5 Feb  7 18:17 bar.txt
-rw------- 1 elias  nogroup   4 Feb  5 23:09 foo.txt
$ cat /mnt/bar.txt
blah
$ echo foo >>/mnt/bar.txt
bash: /mnt/bar.txt: Permission denied
$ cat /mnt/foo.txt
cat: /mnt/foo.txt: Permission denied
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000_GBjtDP
Default principal: elias@REALM

Valid starting       Expires              Service principal
09/02/2013 09:40:47  10/02/2013 09:40:44  krbtgt/REALM@REALM
09/02/2013 09:41:56  10/02/2013 09:40:44  nfs/lion.domain@REALM

Конфигурация сервера

У меня возникли некоторые проблемы с поиском подробного руководства по настройке NFSv4 на FreeBSD. Это само по себе несколько удивительно, поскольку я обнаружил, что информация о том, как что-то делать во FreeBSD, очень хороша.

Вот соответствующие строки в /etc/rc.conf:

rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
nfsuserd_enable="YES"
nfscbd_enable="YES"
mountd_enable="YES"
gssd_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"
zfs_enable="YES"

Вот содержание /etc/exports:

/export/shared/testshare -sec=krb5p
V4: / -sec=krb5p

Еще один интересный аспект: когда я использовал tcpdump для записи сетевого трафика NFS между клиентом и сервером я видел NFS3 пакеты вместе с NFS4 пакеты. Оба этих типа пакетов содержали зашифрованные данные, поэтому я все еще думаю, что использовался Kerberos, но, учитывая приведенную выше конфигурацию, я ожидал, что не будет ничего, кроме трафика NFS4.

Я решил проблему. После просмотра кода я обнаружил, что причиной является ошибка в библиотеке GSS. Проблема была вызвана буфером, отправленным на getpwnam_r это было слишком мало.

Все подробности можно найти в обсуждении на список рассылки

Проще говоря, должен быть какой-то способ сопоставить имена пользователей между системами. Вы используете idmapd как на сервере, так и на клиенте? Ldap?

По крайней мере, в качестве теста попробуйте сделать определенные сопоставления между именами ... кроме root, по крайней мере, на начальном этапе.

  1. Необходимо отключить nfs3 с помощью vfs.nfsd.server_min_nfsvers=4.
  2. Чтобы избежать «никого», клиент и сервер NFSv4 должны находиться в одном месте. домен царство.