From owner-freebsd-net@freebsd.org Sun Oct 23 22:02:09 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 19452C1E625 for ; Sun, 23 Oct 2016 22:02:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0094.outbound.protection.outlook.com [157.56.110.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFA80795 for ; Sun, 23 Oct 2016 22:02:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM (10.165.218.133) by YTXPR01MB0192.CANPRD01.PROD.OUTLOOK.COM (10.165.218.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Sun, 23 Oct 2016 22:01:59 +0000 Received: from YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) by YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM ([10.165.218.133]) with mapi id 15.01.0679.015; Sun, 23 Oct 2016 22:01:59 +0000 From: Rick Macklem To: Ben Whaley , "freebsd-net@freebsd.org" Subject: Re: NFSv4 exports confusion Thread-Topic: NFSv4 exports confusion Thread-Index: AQHSLWucozDdtL+lyE6vm6JZQIT3LaC2kR0r Date: Sun, 23 Oct 2016 22:01:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-office365-filtering-correlation-id: 02dd5110-0d14-421d-5e15-08d3fb903636 x-microsoft-exchange-diagnostics: 1; YTXPR01MB0192; 7:pss6l9OT1n9oDDJkLj14d4cztseM83QgmrjTsL+lzUCHSRGokslarRgNHmuobcVIVkjkXaTevspEY9yQeEtPuQ0lGcy9eLsrvbkdzTx6p6plbXocI8xdPB9W0bw8mxbT0OVI8nW1EnT8JPYJSNTHA+PffnPcad1nQMgA8Zvf57L+y+izO2YWojCoHeqf8IxirzC4r5FeJvIHsvGMDRqgoE31qfwTfyn8D/U52Qu0xYdpgqtn2jI5qMnNhR/nlQKqglvq6r7R00TTTqnj19G92+0+yUvBmd+TAISprewSXvHFX6o+/YQw3xn8Gou00Ph8CjkKCgTEN5/9GiBO+pPGHxDPRTx9eLnFirOMFnOTqyg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:YTXPR01MB0192; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6042046)(6043046); SRVR:YTXPR01MB0192; BCL:0; PCL:0; RULEID:; SRVR:YTXPR01MB0192; x-forefront-prvs: 0104247462 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(174864002)(53754006)(189002)(199003)(9686002)(107886002)(122556002)(3660700001)(189998001)(68736007)(3280700002)(92566002)(86362001)(7696004)(33656002)(2906002)(8936002)(2950100002)(5002640100001)(102836003)(5001770100001)(8676002)(106356001)(97736004)(50986999)(10400500002)(54356999)(2501003)(76176999)(2900100001)(87936001)(77096005)(74482002)(586003)(305945005)(5660300001)(74316002)(101416001)(11100500001)(7846002)(81166006)(106116001)(7116003)(105586002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR01MB0192; H:YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2016 22:01:59.0395 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR01MB0192 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: Sun, 23 Oct 2016 22:02:09 -0000 Ben Whaley wrote: > Hi all, > > I=92m probably just misunderstanding something pretty basic here so apolo= gies > if that=92s the case. > > The NFSv4 pseudo-filesystem root is not behaving the way I=92d expect. > Consider the following extremely simple /etc/exports (just for example > purposes): FreeBSD does not implement a pseudo-filesystem (which was just a suggested 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 t= he 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 the = same server file system. Exports are handled by the FreeBSD kernel on a per-serv= er-filesystem basis. --> As such this line exports the file system /export to 172.28.0.0 and any= where in that file system is exported. If you only want /export/export1 and /export/export2 to be exported, they n= eed to be separate server file systems and need to be exported by separate lines i= n /etc/exports. (The two directories /export/export1 and /export/export2 on the above line = are referred to as "administrative control". In practice that means that the N= FSv3 mount protocol implemented by mountd(8) will only accept those paths. The rest o= f 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 kern= el 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 c= omplicated 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 > `=97 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 them 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= . >=20 > Why is this? The language in RFC7530 seems explicit to me: > > Portions of the server namespace that are not exported are bridged via a >=93pseudo-file system=94 that provides a view of exported directories 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 be > traversed to reach all exports. I am not aware of exactly what the Linux server does these days. At one tim= e, 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 s= eemed to care, so I tossed it. As I noted above, only Solaris ever did a real ps= eudo-fs as far as I am aware and everyone assumed the RFC described it just to demonstrat= e 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=20 Subtrees are segmented on file system mount points in the server. In this c= ase, it refers to one or more file systems that need to be traversed on the way = to the file systems that are actually exported. rick=