From owner-freebsd-current@freebsd.org Mon May 8 13:43:06 2017 Return-Path: Delivered-To: freebsd-current@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 D4F89D62B27 for ; Mon, 8 May 2017 13:43:06 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id A466F873 for ; Mon, 8 May 2017 13:43:06 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id D9EE756495; Mon, 8 May 2017 08:43:05 -0500 (CDT) Subject: Re: more default uid/gid for NFS in mountd To: Rick Macklem , Slawa Olhovchenkov , "freebsd-current@freebsd.org" References: From: Eric van Gyzen Message-ID: Date: Mon, 8 May 2017 08:43:02 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:43:07 -0000 On 05/08/2017 06:45, Rick Macklem wrote: > Hi, > > Five years ago (yea, it slipped through a crack;-), Slawa reported that files > created by root would end up owned by uid 2**32-2 (-2 as uint32_t). > This happens if there is no "-maproot=" in the /etc/exports line. > > The cause is obvious. The value is set to -2 by default. > > The question is... Should this be changed to 65534 (ie "nobody")? > - It would seem more consistent to make it the uid of nobody, but I can also see > the argument that since it has been like this *forever*, that changing it would be > a POLA violation. > What do others think? Since the change is easily communicated in the release notes, I think it seems quite reasonable, especially if you limit it to 12.0. > It is also the case that mountd.c doesn't look "nobody" up in the password database > to set the default. It would be nice to do this, but it could result in the mountd daemon > getting "stuck" during a boot waiting for an unresponsive LDAP service or similar. > Does doing this sound like a good idea? I imagine the lookup could be useful in heterogeneous networks. You might consider adding a CLI flag to mountd to let the admin choose the user by UID/GID, and possibly by username/groupname. That would be a reasonable workaround for networks that often hit the lookup problem. Eric