On Mon, Jan 26, 2015 at 01:20:28PM -0800, Devin Teske wrote: > > > On Jan 25, 2015, at 7:31 AM, Bruce Evans <b...@optusnet.com.au> wrote: > > > > On Sun, 25 Jan 2015, Slawa Olhovchenkov wrote: > > > >> On Sun, Jan 25, 2015 at 04:56:24PM +1100, Bruce Evans wrote: > >> > >>> Negative ids have historical abuses in places like mountd. > > Which paves the way for the “accepted practice” argument > and backed up by “in-the-field usage” statement(s). > > > > >>> 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. > >> > >> This is not full true for ZFS case. > >> On ZFS nobody is 2^32-2. > > > > File systems don't get to decide this. > > +1 (and thanks for the historical account, bruce — sincerely) > > However, I still want to make the argument that: > > a. Because we’ve supported mapping negative inputs to unsigned values in pw > *for over a decade*, that… > > b. We should either revert or make a relnotes submission to note that we’re > changing the long-standing accepted practice. > > Changing the accepted practice broke code internally, it would have likely > broken some external code as well — and people deserve to know about said > change else we should continue to support accepted practice that is decade(s) > old.
It has never been accepted by pw(8) it was just not checked as a result it was accepting *anything* and passed it unchecked directly to atoi(3) resulting in for example pw groupdel -u plop removing wheel... or pw userdel -u something trying to delete root. (was this an accepted behaviour for a decade as well?) Regards, Bapt
pgpVT9ifsVm_Z.pgp
Description: PGP signature
