Я пытаюсь разрешить моему серверу NFS некорневой монтировать запросы.
Сервер: Debian Squeeze, ядро 2.6.32-5-686
Что у меня есть: root (или sudoes) может монтировать файловые системы NFS, но обычные пользователи не могут.
Почему я думаю, что это вообще возможно:
I. Сервер Debian (10.18.51.1)
Установленные пакеты: nfs-kernel-server, nfs-common, portmap
1) / etc / exports:
/usr/appl/ 10.18.51.0/24(ro,no_subtree_check)
/usr/private/ 10.18.51.11(rw,sync,no_subtree_check)
2) / var / lib / nfs / etab
/usr/private 10.18.51.11(rw,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
/usr/appl 10.18.51.0/24(ro,sync,wdelay,hide,nocrossmnt,secure,root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
3) Разрешения на экспортированные папки:
$ ls -lh -d /usr/appl
drwxr-xr-x 3 root root 4.0K Feb 25 17:16 /usr/appl
$ ls -lh -d /usr/private
drwxrwxrwx 4 root root 4.0K Feb 27 12:19 /usr/private
II. Клиент Ubuntu (10.18.51.11)
Установленные пакеты: nfs-common portmap
$ mount 10.18.51.1:/usr/appl /mnt/nfs/appl
mount: only root can do that
Несмотря на то, что в / etc / fstab есть тег пользователя:
10.18.51.1:/usr/appl /mnt/nfs/appl nfs ro,async,nodev,nosuid,user 0 0
10.18.51.1:/usr/private /mnt/nfs/private nfs rw,rsize=8192,hard,intr,nfsvers=3,tcp,noatime,nodev,async,user 0 0
III. Клиент FreeBSD (10.18.51.3)
1)
$ cat /etc/rc.conf
...
nfs_client_enable="YES"
2)
$ mount 10.18.51.1:/usr/appl /mnt/nfs/appl
[tcp] 10.18.51.1:/usr/appl: Permission denied
[tcp] 10.18.51.1:/usr/appl: Permission denied
[tcp] 10.18.51.1:/usr/appl: Permission denied
...
Интересно, что сразу после нажатия Enter он печатает Permission denied, затем ждет некоторое время, затем пытается подключиться к 10.18.51.1, затем снова печатает Permission denied. Я знаю о подключении к серверу, потому что использовал tcpdump (хост tcpdump 10.18.51.3) на сервере:
$ sudo tcpdump host 10.18.51.3
[sudo] password for sukharevd:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:32:28.029560 ARP, Request who-has msiuioo.local tell 10.18.51.3, length 28
23:32:28.029598 ARP, Request who-has msiuioo.local tell 10.18.51.3, length 28
23:32:28.029661 ARP, Reply msiuioo.local is-at 00:21:85:51:44:02 (oui Unknown), length 28
23:32:28.031075 IP 10.18.51.3.35034 > msiuioo.local.sunrpc: UDP, length 56
23:32:28.031401 IP msiuioo.local.sunrpc > 10.18.51.3.35034: UDP, length 28
23:32:28.033275 IP 10.18.51.3.17157 > msiuioo.local.<b>nfs</b>: Flags [S], seq 4085518488, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 405930 ecr 0], length 0
23:32:28.033326 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [S.], seq 1703965537, ack 4085518489, win 5792, options [mss 1460,sackOK,TS val 2186703 ecr 405930,nop,wscale 6], length 0
23:32:28.034717 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [.], ack 1, win 8326, options [nop,nop,TS val 405930 ecr 2186703], length 0
23:32:28.034912 IP 10.18.51.3.4026012106 > msiuioo.local.<b>nfs</b>: 40 null
23:32:28.034978 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [.], ack 45, win 91, options [nop,nop,TS val 2186704 ecr 405930], length 0
23:32:28.035063 IP msiuioo.local.nfs > 10.18.51.3.4026012106: reply ok 24 null
23:32:28.036892 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [F.], seq 45, ack 29, win 8326, options [nop,nop,TS val 405930 ecr 2186704], length 0
23:32:28.036986 IP msiuioo.local.nfs > 10.18.51.3.17157: Flags [F.], seq 29, ack 46, win 91, options [nop,nop,TS val 2186704 ecr 405930], length 0
23:32:28.039021 IP 10.18.51.3.17157 > msiuioo.local.nfs: Flags [.], ack 30, win 8325, options [nop,nop,TS val 405930 ecr 2186704], length 0
23:32:28.039124 IP 10.18.51.3.40381 > msiuioo.local.sunrpc: UDP, length 56
23:32:28.039426 IP msiuioo.local.sunrpc > 10.18.51.3.40381: UDP, length 28
Какие-либо предложения?
UPD: Решил половину проблемы. Я должен был использовать
mount /mnt/nfs/appl
вместо того
mount 10.18.51.1:/usr/appl /mnt/nfs/appl
на клиенте Linux (Ubuntu).
Но все еще есть проблема с монтированием во FreeBSD.
Наиболее вероятная причина возникновения проблем с монтированием без полномочий root - это опция «безопасного» экспорта, которая включена по умолчанию. Он запрещает запросы монтирования, которые поступают с исходным портом больше 1024. В большинстве систем для привязки к порту меньше 1024 требуется root-доступ, так что это довольно приличный способ гарантировать, что монтирование было выполнено root.
Проблема, как объясняется в ПРОЧТИ МЕНЯ для моего инструмента тестирования на проникновение NfSpy заключается в том, что протокол NFS (версии 2, 3 и даже 4, без надлежащей конфигурации) полностью доверяет идентификатору пользователя, отправляемому в запросах с клиентских машин. Ограничивая запросы только теми, которые сделаны root, вы ограничиваете свое доверие только пользователям на клиентской машине, у которых есть root-доступ. Без этого параметра (используя «небезопасный» в вашем файле экспорта) любой пользователь может заявить, что имеет любой UID и получить доступ к любому файлу при экспорте.
Причина, по которой он работает в Linux, вероятно, связана с тем, что / bin / mount имеет setuid root:
~$ ls -l /bin/mount
-rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount
Просто догадка, но проверьте разрешения на монтируемый двоичный файл в вашей системе FreeBSD. Если это является setuid, значит у вас все еще есть проблема, и я не знаю, в чем она. Если нет, то это объяснит, что происходит.
Удачи с этим, но, пожалуйста, рассмотрите последствия для безопасности, позволяя любому пользователю системы получить доступ к любому файлу на вашем сервере. Я рекомендую использовать NFS4 с механизмами аутентификации GSS вместо традиционного варианта AUTH_SYS.