Date: Tue, 27 Jan 2015 23:31:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: svn-src-head@freebsd.org, Baptiste Daroussin <bapt@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r277652 - in head/usr.sbin/pw: . tests Message-ID: <alpine.BSF.2.11.1501272326010.53416@fledge.watson.org> In-Reply-To: <20150125155254.V1007@besplex.bde.org> References: <201501241913.t0OJD4xT039188@svn.freebsd.org> <20150125155254.V1007@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 25 Jan 2015, Bruce Evans wrote: > Negative ids have historical abuses in places like mountd. mountd still > hard-codes -2 and -2 for the default uid and gid of an unprivileged user. It > at least casts these values to uid_t and gid_t before using them. This gives > the ids the non-random values of UINT32_MAX-1 if uid_t and gid_t are > uint32_t. (If uid_t and gid_t were signed, then it would leave the values > as negative, so invalid.) These magic values may work better than when ids > were 16 bits, since there is less risk of them conflicting with a normal id. > However, the non-conflict is probably a bug. FreeBSD uses the magic ids of > 65534 for user nobody: group nobody. These would have been (id_t)-2 with > 16-bit ids. They no longer match, so ls displays (id_t)-2 numerically. > FreeBSD also has a group nogroup = 65553 that doesn't match the nfs usage. > However2, in FreeBSD-1 wher ids were 16-bits, nobody was 32767 and nogroup > was 32766. so they didn't match nfs for other reasons. The 2 non-groups now > seem to be just a bug -- FreeBSD-1 didn't have group nobody. 4.4BSD-Lite2 > has the same values as FreeBSD-1. I'm sure it goes without saying, but for those that don't know (i.e., some subset of people who are not Bruce): (-1) has a defined value both for our system-call interface (chown(2), fchown(2), etc, use (-1) to indicate that no change is requested). This is also used inside the kernel to similar end, where VNOVAL also takes on a value of (-1). This problem also used to exist in NFS, where in NFSv2, (-1) was also used to indicate which fields not to update, but this was fixed in NFSv3 by introducing discriminated unions. I personally find myself a fan of fixing (eliminating) VNOVAL, but in the end it would likely just be disruptive and confusing. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.11.1501272326010.53416>