Date: Sun, 14 May 2017 01:12:11 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: more default uid/gid for NFS in mountd Message-ID: <YTXPR01MB0189D5B7CADD42D195E9855BDDE00@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20170508134203.GA3165@zxy.spb.ru> References: <YTXPR01MB01895E8D60DD369C1762785DDDEE0@YTXPR01MB0189.CANPRD01.PROD.OUTLOOK.COM>, <20170508134203.GA3165@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Slawa Olhovchenkov wrote: >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=3D<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? > >IMHO uid 2**32-2 is POLA violation. >Nobody expect this uid. Too much number. This is like bug. This is what I have just committed. Thanks for the comments. >> It is also the case that mountd.c doesn't look "nobody" up in the passwo= rd 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 o= r similar. >> Does doing this sound like a good idea? > >This is (stuck at boot) already do for case of using NIS and nfsuserd. There is a difference here. nfsuserd mpas between uid/names, so it can't wo= rk without the password database. mountd can work without the password database, so I held off on doing this = for now. >I am regular see this for case of DNS failed at boot. >You offer don't impair current behaviour. As an aside, if you have the critical entries in the local files (/etc/host= s, /etc/passwd, /etc/group) and then tell the libraries to search these first in /etc/nsswi= tch.conf, then you usually avoid this problem. Thanks for the comments, rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB0189D5B7CADD42D195E9855BDDE00>