From owner-freebsd-net@FreeBSD.ORG Tue Jul 29 21:59:39 2014 Return-Path: Delivered-To: freebsd-net@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 ESMTPS id C580C907 for ; Tue, 29 Jul 2014 21:59:39 +0000 (UTC) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9AE642ADA for ; Tue, 29 Jul 2014 21:59:39 +0000 (UTC) Received: by quine.pinyon.org (Postfix, from userid 122) id 4720E1602CD; Tue, 29 Jul 2014 14:59:38 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 142CA160189; Tue, 29 Jul 2014 14:59:36 -0700 (MST) Message-ID: <53D81947.2060801@pinyon.org> Date: Tue, 29 Jul 2014 14:59:35 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rick Macklem , freebsd-net@freebsd.org Subject: Re: nfsd spam in /var/log/messages References: <1188535120.4997158.1406666900373.JavaMail.root@uoguelph.ca> In-Reply-To: <1188535120.4997158.1406666900373.JavaMail.root@uoguelph.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 21:59:39 -0000 On 07/29/14 13:48, Rick Macklem wrote: > Russell L. Carter: > > The "directories within a file system" exports are only enforced by > the Mount protocol that NFSv3 uses to talk to mountd. (NFSv4 does not > use the Mount protocol.) These are considered "administrative controls", > which is a nice way of saying "they aren't actually enforced by the kernel > because there is no easy way to do so, but will discourage trivial attempts > to do NFSv3 mounts". > > Personally, I've never liked these "administrative controls", but others > feel they are useful (introduced long long ago by SunOS) and getting rid > of them would be considered a POLA violation. (This was one of the reasons > why nfse was never adopted as a replacement for mountd.) > > Various people have tried to clarify this in "man exports". Any patches > that improve this will be appreciated. (It just seems to be a difficult > thing to explain.) I performed two more experiments with more than one "V4:" line in exports(5) (all zfs sharenfs=on filesystems): V4: /export/usr V4: /export/library and V4: /export V4: /export2 but mountd complains e.g.: "different V4 dirpath /export/usr" (Note that the So to tighten up just slightly the situation as you have described it: "There can only be one NFSv4 root filesystem per server, and any client host granted NFSv4 access to any subdirectory of that root exported filesystem can also mount any other subdirectory of the root exported filesystem." Why not just say this in exports(5)? As I originally observed, another way of saying this is that for -sec=sys, no per-host (or per-network) access control for the subdirectories of the single NFSv4 exported filesystem is possible. I don't actually think very much is problematical about this situation, because w/o krb5 the protocol is insecure (IMHO). I was just very curious what the current state of play was, *exactly*. Anyway, thanks for your patience explaining this stuff to me. Ok, I think that I can stop gnawing on this bone now... Best, Russell