Может ли кто-нибудь вкратце описать мне, в чем самое большое различие между аутентификацией SMB и аутентификацией NFS v.3?
Я думаю, что в SMB он основан на логине и пароле пользователя, тогда как в NFS он основан на аутентификации хоста.
Он у вас практически есть.
SMB / CIFS основывает доступ на учетных данных пользователя определенного типа (будь то токены KRB, пары пользователь / пароль или что-то еще) для каждого сеанса, где каждый сеанс сопоставляется с одним пользователем. NFSv3 использует аутентификацию на основе хоста, когда все пользователи данной удаленной машины используют одно и то же соединение. SMB / CIFS, особенно реализация Samba, также позволяет разрешить / запретить на основе хоста, если вам нужна эта функция; оконный файловый сервер, вероятно, делает то же самое, и если не в подсистеме файлового сервера, брандмауэр будет обрабатывать его.
SMB / CIFS также реализует аутентификацию на основе общего ресурса, когда общий ресурс имеет свой собственный пароль.
NFSv4 можно настроить для использования аутентификации каждого пользователя через Kerberos.
NFSv3 сильно полагается на удаленный компьютер для обеспечения разрешений, надеясь, что удаленный отправляет правдивые, согласованные между машинами числовые идентификаторы в запросах, тогда как SMB / CIFS обеспечивает разрешения на локальном диске на основе подключения (сеанса) удаленного пользователя, прошедшего проверку подлинности.
Как следствие, в NFSv3, если у пользователя есть root на удаленном компьютере, он обычно (то есть по умолчанию) имеет root-доступ только для чтения ко всей общей папке NFSv3 и может олицетворять любой другой ID пользователя. Для общего доступа к однопользовательской машине в NFS есть all_squash в качестве обходного пути, но это для каждого IP.
С другой стороны, большинство unix-подобных реализаций smb.mount (linux pre-3.3, freebsd, solaris) не поддерживают общесистемное многосессионное (многопользовательское) монтирование, поэтому при монтировании удаленной файловой системы SMB сеанс вашей системы будет таким же только пользователь, установленный на монтаж, а именно. все пользователи действуют с разрешениями имени пользователя, установленными во время монтирования. Linux 3.3 и более поздние версии имеют cifscreds для смягчения последствий, а также доступны реализации FUSE SMB / CIFS. Как и ожидалось, с клиентами Windows это никогда не было проблемой.
Также в NFSv3 ваши числовые UID должны точно соответствовать: пользователю 1001 на клиентской машине будут предоставлены разрешения как пользователю 1001 на сервере; нет текстового сопоставления имен пользователей. Поскольку SMB / CIFS привязывает идентификатор к сеансу, сопоставление выполняется автоматически; ваш общий UID соответствует вашим учетным данным.
В NFSv4 есть демон для сопоставления идентификаторов пользователей, прошедших аутентификацию в GSS-домене, но если у вас еще нет развернутого GSS-домена, вероятно, будет проще синхронизировать ваши UID.
NFSv3 и более ранние версии могут быть немного схематичными с поддержкой ACL (а xattrs прямо здесь). «POSIX ACL» NFS реализованы в RPC боковой полосы (не в основном протоколе), поэтому есть еще несколько вещей, которые могут пойти не так, и не все ОС поддерживают POSIX ACL NFS.
SMB / CIFS обычно не имеет проблем с ACL. Если вам нужно их изменить, Windows и unix-подобные клиенты могут изменять общие ресурсы Samba с помощью своих стандартных механизмов (GUI и setfacl соответственно). Я не уверен, могут ли unix-подобные клиенты изменять разрешения, подобные ACL, для общей папки файлового сервера Windows.
NFSv4 имеет встроенные списки контроля доступа.
SMB и NFS - это просто транспортные протоколы для перемещения данных по сетевому соединению. Протоколы не обеспечивают какой-либо аутентификации. Сервер, на котором размещен общий ресурс, должен обеспечивать аутентификацию и разрешать / запрещать запросы на соединение.