From owner-freebsd-net@freebsd.org Sat Apr 16 04:27:52 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 9EB3EB10F36 for ; Sat, 16 Apr 2016 04:27:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 595E91B14 for ; Sat, 16 Apr 2016 04:27:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c110-21-41-193.carlnfd1.nsw.optusnet.com.au (c110-21-41-193.carlnfd1.nsw.optusnet.com.au [110.21.41.193]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1F68B424B3B; Sat, 16 Apr 2016 13:59:36 +1000 (AEST) Date: Sat, 16 Apr 2016 13:59:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Raimundo Santos cc: "freebsd-net@freebsd.org" Subject: Re: Why anyone can read and write to a nobody NFS mounted volume? In-Reply-To: Message-ID: <20160416100811.Y905@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=EfU1O6SC c=1 sm=1 tr=0 a=73JWPhLeruqQCjN69UNZtQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=B6pfZmMIkaIzbGj7saIA:9 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2016 04:27:52 -0000 On Fri, 15 Apr 2016, Raimundo Santos wrote: > i have a strange situation: everyone and not just root can read and write > to a NFS mount point whose owner is nobody:nobody. > > Is this an expected behaviour? > > FreeBSD 10.2 RELEASE as NFS client. > Seagate NAS400 as NFS server. This is, unfortunately, expected. The defaults for nobody used to be 32767:9999. This was broken in FreeBSD in 1995 by changing them to 65534:65534. This conflicts with the best defaults for maproot and mapall on nfs servers. nfs servers should default to mapping to ids below 65535, so that the defaults work on clients with 16-bit ids. 65534 is a good choice, unless you want to support clients with 8-bit ids, when 254 is a good choice. Your server apparently uses good defaults, giving the expected conflict with the misconfigured client. This bug is normally not noticed, since FreeBSD servers are misconfigured by default to the mappings -2:-2. -2 is an invalid id. It last worked in FreeBSD-1. Then 3 or 4 layers of magic turned this into the good value of 65534. The magic included ids being 16 bits. It would have worked right to reduce 65534 to 254 if ids had been reduced to 8 bits, but it worked wrong to increase 65534 to 4294967294 when ids were increased to 32 bits. 4294967294 not only breaks 16-bi clients; it is too hard to remember or type, and is misparsed by the parser in mountd. The misconfigurations compensate for each other. See exports(5) for less details. Bruce