Date: Mon, 8 May 2017 08:43:02 -0500 From: Eric van Gyzen <eric@vangyzen.net> To: Rick Macklem <rmacklem@uoguelph.ca>, Slawa Olhovchenkov <slw@zxy.spb.ru>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: more default uid/gid for NFS in mountd Message-ID: <f1abdf1a-efde-4ee2-c2e3-d39f0cf8fe0f@vangyzen.net> In-Reply-To: <YTXPR01MB01895E8D60DD369C1762785DDDEE0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> References: <YTXPR01MB01895E8D60DD369C1762785DDDEE0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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=<user>" 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f1abdf1a-efde-4ee2-c2e3-d39f0cf8fe0f>