From owner-freebsd-questions@FreeBSD.ORG Wed Oct 16 09:28:25 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2668570E for ; Wed, 16 Oct 2013 09:28:25 +0000 (UTC) (envelope-from ml@netfence.it) Received: from smtp.eutelia.it (mp1-smtp-6.eutelia.it [62.94.10.166]) by mx1.freebsd.org (Postfix) with ESMTP id A66382E1C for ; Wed, 16 Oct 2013 09:28:23 +0000 (UTC) Received: from ns2.biolchim.it (ip-188-188.sn2.eutelia.it [83.211.188.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.eutelia.it (Eutelia) with ESMTP id 82A8E687ED7 for ; Wed, 16 Oct 2013 11:28:16 +0200 (CEST) Received: from soth.ventu (adsl-ull-161-224.41-151.net24.it [151.41.224.161]) (authenticated bits=0) by ns2.biolchim.it (8.14.7/8.14.7) with ESMTP id r9G9SBdk003845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 16 Oct 2013 11:28:12 +0200 (CEST) (envelope-from ml@netfence.it) X-Authentication-Warning: ns2.biolchim.it: Host adsl-ull-161-224.41-151.net24.it [151.41.224.161] claimed to be soth.ventu Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.7/8.14.7) with ESMTP id r9G9S5x1083116 for ; Wed, 16 Oct 2013 11:28:05 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <525E5C25.5070305@netfence.it> Date: Wed, 16 Oct 2013 11:28:05 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: NFSv4 security Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (ns2.biolchim.it [192.168.2.203]); Wed, 16 Oct 2013 11:28:12 +0200 (CEST) X-Scanned-By: MIMEDefang 2.74 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:28:25 -0000 Hello. Since I replaced my server with a 9.2 one, I'm playing with NFSv4 to test it. However something does not work as I expect and I'm not sure if I understand it correctly or am doing some mistake. Server side, this was my export: >/usr/home /usr/ports -maproot=root 192.168.0.15 To enable NFSv4, I changed it like this: >V4:/ 192.168.0.15 >/usr/home /usr/ports -maproot=root 192.168.0.15 (Of course, in the example above, I could root V4 at /usr, but this is going to grow; besides, this is not the point). Now, on the client, I can: >mount -o nfsv4 192.168.0.1:/usr/ports /mnt/temp/ or >mount -o nfsv4 192.168.0.1:/usr/home /mnt/temp/ Both work. Now, let's try to break in, going where I don't think I should be able to go. >mount -o nfsv4 192.168.0.1:/ /mnt/temp/ This is allowed; no surprises; quoting "man nfsv4": > The > nfsd(8) allows a limited subset of operations to be performed on non- > exported subtrees of the local file system, so that traversal of the tree > to the exported subtrees is possible. Well, let's try it: > # ls /mnt/temp/ (no output) Fine. > # ls /mnt/temp/usr > .snap bin games home include lib lib32 libdata libexec local obj ports sbin share src Strange, I though I would get an empty list here, too (!!!!). > # ls /mnt/temp/usr/bin/ > CC chsh file ipcs mailq pawd soelim users > Mail ci file2c jobs mailx perl sort uudecode > addftinfo cksum find join make perl5 split uuencode > addr2line clang finger jot makeinfo perror sscop vacation > afmtodit clang++ flex kadmin makewhatis pfbtops ssh verify_krb5_conf > ... What??? /usr/bin is not needed to get to /usr/home or /usr/ports/. > # touch /mnt/temp/usr/bin/newbin > # ls /mnt/temp/usr/bin/|grep newbin > newbin Hell! This is NOT supposed to work, as far as I understand it. Why this? Did I understang the docs wrong? (Besides, can someone give any link to a good description of how and why this tree thing was introduced?). Is this some sort of interaction with older NFS? Is something wrong with the following fragment of my server-side rc.conf: > #New NFSv4 config > rpcbind_enable="YES" > rpcbind_flags="-ls" > nfs_server_enable="YES" > nfsv4_server_enable="YES" > nfsuserd_enable="YES" > #Old NFSv3 config, might be removed in the future > nfs_server_flags="-u -n 8 -t" > nfs_reserved_port_only="YES" > rpc_statd_enable="YES" > rpc_statd_flags="-p 918" > rpc_lockd_enable="YES" > rpc_lockd_flags="-p 868" > #mountd_enable="YES" > mountd_flags="-p 685" bye & Thanks av.