NFS. Richieste di assembly non root

Sto cercando di rendere il mio server NFS consentire le richieste di assembly non root .

Server: Debian Squeeze, kernel 2.6.32-5-686

Quello che ho adesso: root (o sudoes) può montare i file system NFS, ma gli utenti normali non possono.

Perché penso che sia ansible:

  1. Documentazione di FreeBSD: http://www.unix.com/man-page/FreeBSD/8/mountd/ option -n
  2. Domande su forum orientati a Linux, come questo: http://www.linuxquestions.org/questions/linux-software-2/non-root-account-unable-to-mount-a-nfs-connection-926985/

I. Server Debian (10.18.51.1)

Pacchetti installati: 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) Autorizzazioni alle cartelle esportte:

 $ 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 client (10.18.51.11)

Pacchetti installati: nfs-common portmap

 $ mount 10.18.51.1:/usr/appl /mnt/nfs/appl mount: only root can do that 

Nonostante ci sia un tag utente in / 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. Client 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 ... 

Interessante che appena dopo premere Invio printing Permessi negato, quindi attende un po 'di tempo, quindi si tenta di connettersi a 10.18.51.1, quindi printing Permission negato di nuovo. So di connettersi al server perché ho usato tcpdump (tcpdump host 10.18.51.3) sul server:

 $ 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 

Eventuali suggerimenti?

UPD: risolto metà di un problema. Avrei dovuto usare

 mount /mnt/nfs/appl 

invece di

 mount 10.18.51.1:/usr/appl /mnt/nfs/appl 

su un client Linux (Ubuntu).

Ma ha ancora problemi con il assembly in FreeBSD.

One Solution collect form web for “NFS. Richieste di assembly non root”

Il motivo più probabile che si riscontrano problemi con i montanti non root è l'opzione di esportzione "sicura", triggers per impostazione predefinita. Distriggers le richieste di mount che vengono fornite con una port di origine superiore a 1024. Nella maggior parte dei sisthemes, la connessione a una port inferiore a 1024 richiede l'accesso principale, quindi è un modo abbastanza decente per assicurare che il assembly sia stato eseguito da root.

Il problema, come spiegato nella versione README per il mio strumento di test di penetrazione NfSpy, è che il protocollo NFS (versioni 2, 3, e perfino 4, senza una corretta configuration) si fida completamente dell'ID utente inviato nelle richieste dalle macchine client. Limitando le richieste a solo quelle fatte da root, limiti la tua fiducia solo agli utenti della macchina client che hanno accesso alla radice. Senza questa impostazione (utilizzando "insecure" nel file di esportzioni), qualsiasi utente può richiedere di avere qualsiasi UID e di accedere a qualsiasi file sull'esportzione.

Il motivo per cui lavora su Linux è probabilmente perché / bin / mount è root setuid:

 ~$ ls -l /bin/mount -rwsr-xr-x 1 root root 72188 2011-01-20 13:54 /bin/mount 

Solo un assaggio, ma controlla le autorizzazioni sul binario mount sul tuo sistema FreeBSD. Se è setuid, allora hai ancora un problema e non so cosa sia. Se no, allora ciò spiegherebbe cosa sta succedendo.

Buona fortuna con questo, ma ti preghiamo di considerare le implicazioni di sicurezza di consentire a qualsiasi utente di un sistema di accedere a qualsiasi file sul server. Raccommand di utilizzare NFS4 con i meccanismi di authentication GSS anziché il tradizionale sapore AUTH_SYS.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.