Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jan 2015 00:44:20 +0100
From:      Baptiste Daroussin <bapt@freebsd.org>
To:        Devin Teske <dteske@FreeBSD.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au>, Slawa Olhovchenkov <slw@zxy.spb.ru>
Subject:   Re: svn commit: r277652 - in head/usr.sbin/pw: . tests
Message-ID:  <20150127234420.GB84622@ivaldir.etoilebsd.net>
In-Reply-To: <5D58B34B-8647-4B69-8D90-E7D37C98D4AD@FreeBSD.org>
References:  <201501241913.t0OJD4xT039188@svn.freebsd.org> <20150125155254.V1007@besplex.bde.org> <20150125142148.GA76051@zxy.spb.ru> <20150126014336.P2572@besplex.bde.org> <5D58B34B-8647-4B69-8D90-E7D37C98D4AD@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--f0KYrhQ4vYSV2aJu
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jan 26, 2015 at 01:20:28PM -0800, Devin Teske wrote:
>=20
> > On Jan 25, 2015, at 7:31 AM, Bruce Evans <brde@optusnet.com.au> wrote:
> >=20
> > On Sun, 25 Jan 2015, Slawa Olhovchenkov wrote:
> >=20
> >> On Sun, Jan 25, 2015 at 04:56:24PM +1100, Bruce Evans wrote:
> >>=20
> >>> Negative ids have historical abuses in places like mountd.
>=20
> Which paves the way for the =E2=80=9Caccepted practice=E2=80=9D argument
> and backed up by =E2=80=9Cin-the-field usage=E2=80=9D statement(s).
>=20
>=20
>=20
> >>>  mountd still
> >>> hard-codes -2 and -2 for the default uid and gid of an unprivileged u=
ser.
> >>> 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 wo=
rk
> >>> 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 =3D 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.
> >>=20
> >> This is not full true for ZFS case.
> >> On ZFS nobody is 2^32-2.
> >=20
> > File systems don't get to decide this.
>=20
> +1 (and thanks for the historical account, bruce =E2=80=94 sincerely)
>=20
> However, I still want to make the argument that:
>=20
> a. Because we=E2=80=99ve supported mapping negative inputs to unsigned va=
lues in pw *for over a decade*, that=E2=80=A6
>=20
> b. We should either revert or make a relnotes submission to note that we=
=E2=80=99re changing the long-standing accepted practice.
>=20
> Changing the accepted practice broke code internally, it would have likel=
y broken some external code as well =E2=80=94 and people deserve to know ab=
out said change else we should continue to support accepted practice that i=
s 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

--f0KYrhQ4vYSV2aJu
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlTIItMACgkQ8kTtMUmk6ExVwwCdE5V/XAfKZ3K6u9iGm4EUBVmX
nYUAoKkQoztNiDHI7ipKwqAzTYZKTV6/
=kC0r
-----END PGP SIGNATURE-----

--f0KYrhQ4vYSV2aJu--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150127234420.GB84622>