Установка для монтирования kerberized корневой каталог nfs - gssd не находящий действительный kerberos билет

Наши корневые каталоги экспортируются через kerberized nfs, таким образом, пользователю нужен действительный kerberos билет, чтобы смочь смонтировать его дом. Эта установка хорошо работает с нашими существующими клиентами и сервером.

Теперь мы хотим добавить приблизительно 11,10 клиентов и таким образом настроить ldap и kerberos вместе с pam_mount. Работы аутентификации LDAP и пользователи могут войти в систему через ssh, однако их дома не могут быть смонтированы.

Когда pam_mount настроен для монтирования, поскольку корень, gssd не находит действительный kerberos билет и сбои монтирования.

Nov 22 17:34:26 zelda rpc.gssd[929]: handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 '
Nov 22 17:34:26 zelda rpc.gssd[929]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt2)
Nov 22 17:34:26 zelda rpc.gssd[929]: process_krb5_upcall: service is '<null>'
Nov 22 17:34:26 zelda rpc.gssd[929]: getting credentials for client with uid 0 for server purple.physcip.uni-stuttgart.de
Nov 22 17:34:26 zelda rpc.gssd[929]: CC file '/tmp/krb5cc_65678_Ku2226' being considered, with preferred realm 'PURPLE.PHYSCIP.UNI-STUTTGART.DE'
Nov 22 17:34:26 zelda rpc.gssd[929]: CC file '/tmp/krb5cc_65678_Ku2226' owned by 65678, not 0
Nov 22 17:34:26 zelda rpc.gssd[929]: WARNING: Failed to create krb5 context for user with uid 0 for server purple.physcip.uni-stuttgart.de
Nov 22 17:34:26 zelda rpc.gssd[929]: doing error downfall

Когда pam_mount, с другой стороны, настроен с noroot=1 опцией, затем это не может смонтировать объем вообще.

Nov 22 17:33:58 zelda sshd[2226]: pam_krb5(sshd:auth): user phy65678 authenticated as phy65678@PURPLE.PHYSCIP.UNI-STUTTGART.DE
Nov 22 17:33:58 zelda sshd[2226]: Accepted password for phy65678 from 129.69.74.20 port 51875 ssh2
Nov 22 17:33:58 zelda sshd[2226]: pam_unix(sshd:session): session opened for user phy65678 by (uid=0)
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(mount.c:69): Messages from underlying mount program:
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(mount.c:73): mount: only root can do that
Nov 22 17:33:58 zelda sshd[2226]: pam_mount(pam_mount.c:521): mount of /Volumes/home/phy65678 failed

Таким образом, как мы можем позволить пользователям определенной группы выполнять, nfs монтируется? Если это не работает, мы можем заставить использование pam_mount базироваться, но передать корректный uid?

17
задан 20 March 2012 в 09:19

1 ответ

Посмотрите этот поток:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190267

Если нет никакой "пользовательской" опции в fstab, только базируйтесь, может смонтировать объемы. Существует некоторый комментарий в mount.c при том, чтобы заставлять монтирование управлять исполняемым файлом любым пользователем, но это было отклонено специалистом по обслуживанию (комментарий говорит что-то о последствиях безопасности, но не более конкретен).

В отличие от исходного восходящего потока, выполняется версия Debian libpam-монтирования, монтируют команды с пользователем uid, не как корень. Выполнение указанное пользователями монтирование как корень является дырой в системе безопасности. Любой пользователь затем мог смонтировать объем к/usr или/tmp на входе в систему или umount любой другой объем на выходе из системы.

Или другими словами libpam-монтирование может сделать только вещи, которые пользователь может сделать, ничто больше.

Так, какие-либо предложения?

Помещение пользовательской записи в fstab должно сделать это. Скажите мне, как это работает. Обратите внимание, что другие файловые системы (ncp, кто-то) имеют вызываемые пользователем двоичные файлы монтирования как smbmount или ncpmount. Там кажется, что ничто как это для обратной петли не монтирует:/

2
ответ дан 23 November 2019 в 02:26

Другие вопросы по тегам:

Похожие вопросы: