From owner-freebsd-net@FreeBSD.ORG Thu Jul 31 13:12:48 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5ECAB88B for ; Thu, 31 Jul 2014 13:12:48 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 235EA2B9F for ; Thu, 31 Jul 2014 13:12:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEADZA2lODaFve/2dsb2JhbABZg2BXBIJ0yBAeCoZ4UwGBHHeEAwEBAQECAQEBASArIAsFFhgCAg0ZAikBCSYGCAcEARwEiBkIDaUql1gXgSyNTwEBGzQHgnmBUQWXPAeBL4REkwGDZSEvB4EFOQ X-IronPort-AV: E=Sophos;i="5.01,772,1400040000"; d="scan'208";a="144566768" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 31 Jul 2014 09:12:40 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EB668B4132; Thu, 31 Jul 2014 09:12:40 -0400 (EDT) Date: Thu, 31 Jul 2014 09:12:40 -0400 (EDT) From: Rick Macklem To: "Russell L. Carter" Message-ID: <1996576511.5775381.1406812360936.JavaMail.root@uoguelph.ca> In-Reply-To: <53D81947.2060801@pinyon.org> Subject: Re: nfsd spam in /var/log/messages MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-net@freebsd.org 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: Thu, 31 Jul 2014 13:12:48 -0000 Russell L. Carter wrote: > > > 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 > Well, I think this one is fairly clearly stated in the description of the "V4:" line, where it says that it must be the same directory path for all entries. > 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. > Yeh, the one about "mounting any subdir" is hidden in the first page of "man exports", where it mentions this and how "-alldirs" is assumed for NFSv4. I think words similar to the above would make it clearer. I'll post a exports(5) patch soon for review. > 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 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" >