Вместо сценария оболочки вы можете использовать внешние команды. 'дерево' может быть доступно в вашей среде, тогда это просто.
tree -d
Ну, я понял, что стоит понять, как 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 выполняет файловую операцию
chown
команда)ls
команда)Это обрабатывается программой id_resolver
upcall, указанной в /etc/request-key.conf
или /etc/request-key.d/*
(, обычноnfsidmap
).
Имена пользователей передаются между хостами в виде строк user@dns_domain
и сопоставляются с локальными uid/gid на каждой стороне.
Фактический пользователь, выполняющий операцию с файлом, получен из билета (, поэтому важно, под каким принципом мы аутентифицируемся ), и НЕ из uid локально запущенного процесса, запрашивающего операцию с файлом. (чего можно было бы наивно ожидать ).
Таким образом, для того, чтобы эффективное сопоставление пользователей работало, необходимо создать username
принципала (эффективноusername@REALM
)или, если используется более сложное имя принципала,обеспечить соответствующее отображение auth_to_local
в /etc/krb5.conf
, как описано здесь
У каждого пользователя должен быть свой собственный участник по умолчанию (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