NFSv4 неправильный эффективный пользователь/владелец, sec=krb5 монтирует сквош для анонимного пользователя

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

В NFS с поддержкой Kerberos необходимо знать разницу между

• эффективный пользователь, выполняющий файловую операцию

  Эффективный (сервер -локальный )пользователь файловой операции определяется локальным интерфейсом авторизации Kerberos , который настраивается с помощью auth_to_localтега ., а если ничего не указано, по умолчанию используется auth_to_local = DEFAULT, операция для которого определяется как

  The principal name will be used as the local user name. If the principal has more than one component or is not in the default realm, this rule is not applicable and the conversion will fail.

  В случае сбоя преобразования предполагается анонимный пользователь(nobody:nogroupили anonuid:anongid, если он указан в записи экспорта )

  .

  Связанное обсуждение, дающее хорошее объяснение.

• параметры/результаты операции с этим файлом

  Когда сервер NFS выполняет файловую операцию

  1. параметры должны быть сопоставлены с клиента -предоставленные пользователи серверу -локальные пользователи(chownкоманда)
  2. результаты необходимо сопоставить с клиентом -локальные пользователи(lsкоманда)

  Это обрабатывается программой id_resolverupcall, указанной в /etc/request-key.confили /etc/request-key.d/*(, обычноnfsidmap).

  Имена пользователей передаются между хостами в виде строк user@dns_domainи сопоставляются с локальными uid/gid на каждой стороне.

Фактический пользователь, выполняющий операцию с файлом, получен из билета (, поэтому важно, под каким принципом мы аутентифицируемся ), и НЕ из uid локально запущенного процесса, запрашивающего операцию с файлом. (чего можно было бы наивно ожидать ).

Таким образом, для того, чтобы эффективное сопоставление пользователей работало, необходимо создать usernameпринципала (эффективноusername@REALM)или, если используется более сложное имя принципала,обеспечить соответствующее отображение auth_to_localв /etc/krb5.conf, как описано здесь

• https://access.redhat.com/articles/4040141
• https://blog.samoylenko.me/2015/04/15/hadoop-security-auth_to_local-examples/
• https://community.cloudera.com/t5/Community-Articles/Auth-to-local-Rules-Syntax/ta-p/245316

У каждого пользователя должен быть свой собственный участник по умолчанию (user/client-fqdn), который используется для сопоставления с локальным пользователем сервера -.

Субъекты-службы используются и авторизуются самими службами, и, по-видимому, пользователям не нужно иметь к ним доступ (они должны быть сохранены в /etc/krb5.keytab, но не в пользовательских клавишных таблицах)

Расположение пользовательской таблицы ключей зависит от дистрибутива -используйте krb5-config, чтобы выяснить, что ожидается от вашей сборки

USER_KEYTAB=$(euid=$EUID; eval echo $(krb5-config --defcktname | tr % $ | sed 's/FILE://'))

Ниже приведена краткая демонстрация того, как правильно настроить сопоставление для пользователя через NFS с поддержкой Kerberos.

Следующая конфигурация была протестирована на системах CentOS, настроенных с помощью этого руководства (руководство предназначено для Centos 7, протестировано на 8, необходимы небольшие дополнения)

https://www.linuxhelp.com/how-to-set-up-nfs-server-with-kerberos-based-authentication

# Start kadmin on client machine (I assume that you have the root/admin principal already set up)
#
[root@nfsclient ~]# kadmin -p root/admin
Authenticating as principal root/admin with password.
Password for root/admin@KDC.COM: 

kadmin:  addprinc -randkey -clearpolicy host/nfsclient
Principal "host/nfsclient@KDC.COM" created.

kadmin:  addprinc -randkey -clearpolicy nfs/nfsclient
Principal "nfs/nfsclient@KDC.COM" created.

kadmin:  ktadd -k /tmp/krb5.keytab host/nfsclient
Entry for principal host/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab.
...

kadmin:  ktadd -k /tmp/krb5.keytab nfs/nfsclient
Entry for principal nfs/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab.
...

kadmin:  addprinc -randkey -clearpolicy testuser
Principal "testuser@KDC.COM" created.

kadmin:  ktadd -k /tmp/client.keytab testuser
Entry for principal testuser with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/client.keytab.
...

kadmin:  quit


# Set up the default keytab (service principals)
[root@nfsclient ~]# mv /tmp/krb5.keytab /etc/krb5.keytab
[root@nfsclient ~]# chown root:root /etc/krb5.keytab

# Set up user keytab
[root@nfsclient ~]# mv /tmp/client.keytab /var/kerberos/krb5/user/$(id -u testuser)/client.keytab
[root@nfsclient ~]# chown testuser:testuser /var/kerberos/krb5/user/$(id -u testuser)/client.keytab

# Mount the filesystem
mount nfsserver.kdc.com:/kerberos /mnt

# Test the user
[root@nfsclient ~]# sudo -i -u testuser

# Check that the users client.keytab, is being picked up
# (can access nfs share)
#
# and that the correct effective user is now used for file operation
# (derived from default principal and mapped to server-local user)
# - the server should also have a `testuser` user
#
[testuser@nfsclient ~]$ touch /mnt/testfile
[testuser@nfsclient ~]$ ls -la /mnt/testfile
-rw-rw-r--. 1 testuser testuser 0 Jun 23 16:31 /mnt/testfile

# After accesses one can check the keys that have been retrieved on 
[testuser@nfsclient ~]$ klist
Ticket cache: KCM:1051:17737
Default principal: testuser@KDC.COM

Valid starting       Expires              Service principal
06/23/2021 16:06:12  06/24/2021 16:06:12  krbtgt/KDC.COM@KDC.COM
        renew until 06/23/2021 16:06:12
06/23/2021 16:06:12  06/24/2021 16:06:12  nfs/nfsserver.kdc.com@KDC.COM
        renew until 06/23/2021 16:06:12