From owner-freebsd-net@freebsd.org Mon Oct 24 14:58:59 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2819BC1EAF0 for ; Mon, 24 Oct 2016 14:58:59 +0000 (UTC) (envelope-from bwhaley@gmail.com) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D92C56A8 for ; Mon, 24 Oct 2016 14:58:58 +0000 (UTC) (envelope-from bwhaley@gmail.com) Received: by mail-yb0-x235.google.com with SMTP id d128so28600925ybh.2 for ; Mon, 24 Oct 2016 07:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NKvvnEuP/GFRNZPIXrMOQrtqMxXeE7mFOPnAInp7p8U=; b=FRL08MmBe7Uqb3SGM8W6TnPJw4ep0kxqd1ORh6O1m3JdOXjIUmDrGXJAQJJ0ROZV18 r1BzGRxrtVRq2WBM7jsxgJegJzEIxfw5DflUxu1F3JEw2W1qL8GdZVETjUDBLUs3/PkH 0Mm+e9xFunpwYl25FR6KUmAnvbctniirJipwnPqQLcJ+SaxcQVb1CXgkamP8ZyE0B+ML X3o6NJITEyTzoVM9lGPKR48Kt/L78Oqwk51gcZfxuCeqFgEqhQARtCdfMZgPYqoct8dq BRti0pgWsoYAlUdMpA+gUX5SS+WOVXDsjJ7HvcOxVEbsOutdxDY5MkV3IxF16HLuVPcj uu1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NKvvnEuP/GFRNZPIXrMOQrtqMxXeE7mFOPnAInp7p8U=; b=aLOWG4qmKVrCLV9yBESVWexAR2ilctg1yMO2u14lazQf+lKwt93qXmlMEMvmJrhNj2 MCIgQOeNoCeHZClHVoiWHehiHfBngKt5sk0gKQXxYwQ4jIaYN3ZJVPazf2cZZIW4xJm5 SE50HvXN3M4GSO9nzsb13sj/iqqfNZklEqdjLmjOJ5sY51v66RfJCklv2Uy5W7bCj8e0 qMBWxYFUGnZBXll66nFQUE0G7jYfcmYr4wrOiTCmsl28Gwql9F6F/nf4/WP2s1/JwJ8d X6nM4kaukBWBOk0efrLp58cO79t4k/dd433o5XHx88Imv+YWSXGdwhvDavM2C5KwKdUu /o7A== X-Gm-Message-State: ABUngvdtWtVC18spSsz9SE6VKQLAogd9GOUaJA1mD1NF0Re6w5iD+mYY0yd7gsIkcSr4IhhAtGHShmBD8p+JOw== X-Received: by 10.107.129.151 with SMTP id l23mr12952973ioi.149.1477321137928; Mon, 24 Oct 2016 07:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.223.131 with HTTP; Mon, 24 Oct 2016 07:58:57 -0700 (PDT) In-Reply-To: References: From: Ben Whaley Date: Mon, 24 Oct 2016 07:58:57 -0700 Message-ID: Subject: Re: NFSv4 exports confusion To: Rick Macklem Cc: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 14:58:59 -0000 Thank you, Rick, for taking the time to reply. In an NFSv4 server, is it possible to have multiple exports on the same filesystem but not under the same tree without exposing the top level directory? E.g. if you wanted to export the following without also exporting / /path/to/export1 /anotherpath/to/export2 Assuming export1 and export2 are both on the same server filesystem, could they both be exported without exporting / as the NFSv4 root? Also, exports(5) says: > The third form has the string ``V4:=E2=80=99=E2=80=99 followed by a singl= e absolute path name, to specify the NFSv4 tree root. > This line does not export any file system, but simply marks where the root of the server=E2=80=99s directory t= ree is for > NFSv4 clients. Yet the V4 root seems to behave like a =E2=80=9Cnormal=E2=80=9D export with= the -alldirs option. A V4 client can mount the V4 root and any subdirectory under it, whether the subdir was exported or not. Am I misunderstanding what the man page says? Thanks again, Ben On Sun, Oct 23, 2016 at 3:01 PM, Rick Macklem wrote: > Ben Whaley wrote: > > > Hi all, > > > > I=E2=80=99m probably just misunderstanding something pretty basic here = so > apologies > > if that=E2=80=99s the case. > > > > The NFSv4 pseudo-filesystem root is not behaving the way I=E2=80=99d ex= pect. > > Consider the following extremely simple /etc/exports (just for example > > purposes): > FreeBSD does not implement a pseudo-filesystem (which was just a suggeste= d > mechanism in the RFC that only Solaris did, as far as I know. > The "V4:" line simply specifies where in the real server file system tree > the NFSv4 root > is. > > > V4: /exports > > /exports/export1 /exports/export2 -network 172.28.0.0/16 > Since these paths are both on the same line, it suggests that they are th= e > same > server file system. Exports are handled by the FreeBSD kernel on a > per-server-filesystem > basis. > --> As such this line exports the file system /export to 172.28.0.0 and > anywhere in > that file system is exported. > If you only want /export/export1 and /export/export2 to be exported, they > need to > be separate server file systems and need to be exported by separate lines > in > /etc/exports. > (The two directories /export/export1 and /export/export2 on the above lin= e > are > referred to as "administrative control". In practice that means that the > NFSv3 mount > protocol implemented by mountd(8) will only accept those paths. The rest > of the > file system is actually exported, but a typical NFSv3 client won't be > able to mount them. > A hacked or malicious one could access the rest of /export, since the > kernel doesn't > know anything about subtrees of a server fiule system.) > > Since NFSv4 doesn't use the Mount protocol (and never talks to mountd(8))= , > it knows > nothing about these "administrative controls". (And, yes, /etc/exports is > complicated > including the man page that tries to explain it.) > --> The behaviour you describe is what is expected to happen, given > /export/export1 > and /export/export2 are on the same server file system. > > > And this directory structure: > > > > # tree /exports/ > > /exports/ > > |-- export1 > > | `-- file1 > > |-- export2 > > | `-- file2 > > `-- notanexport > > `=E2=80=94 file > > > > Now when I mount / as the NFSv4 pseudo-fs root (from an Ubuntu Xenial > > client): > > > > mount -t nfs4 server:/ /mnt > > > > I would expect to see only export1 and export2. But in fact I see > If you want the client to just see export1 and export2, you can mount the= m > individually. For example: > mount -t nfs4 server:/export1 /mnt/export1 > mount -t nfs4 server:/export2 /mnt/export2 > > > # ls /mnt > > export1 export2 notanexport > > > > And the contents of /exports/notanexport/file are available to the > client. > > > > Why is this? The language in RFC7530 seems explicit to me: > > > > Portions of the server namespace that are not exported are bridged via = a > >=E2=80=9Cpseudo-file system=E2=80=9D that provides a view of exported di= rectories only. > > > > E.g. per the spec, only exported filesystems should be visible, and the > > path to get to them. The pseudo-fs only exposes directories that must b= e > > traversed to reach all exports. > I am not aware of exactly what the Linux server does these days. At one > time, > you specified a single file system as the root and the "root of the tree > is there". > (I once did a pseudo-file system, but the code was complicated and no one > seemed > to care, so I tossed it. As I noted above, only Solaris ever did a real > pseudo-fs as far > as I am aware and everyone assumed the RFC described it just to > demonstrate it was a possible solution, not a required one.) > > > > The man page also states: > > > > The nfsd(8) allows a limited subset of operations to be performed on > non-exported >subtrees > > Subtrees are segmented on file system mount points in the server. In this > case, > it refers to one or more file systems that need to be traversed on the wa= y > to the > file systems that are actually exported. > > rick