Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jan 2015 10:56:11 +0100
From:      Baptiste Daroussin <bapt@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        svn-src-head@freebsd.org, dteske@FreeBSD.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r277652 - in head/usr.sbin/pw: . tests
Message-ID:  <20150125095611.GM81001@ivaldir.etoilebsd.net>
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

--C01fF7hLGvN0zd9s
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Jan 25, 2015 at 04:56:24PM +1100, Bruce Evans wrote:
> On Sat, 24 Jan 2015, Baptiste Daroussin wrote:
>=20
> > Log:
> >  Allow negative numbers in -u and -g options
>=20
> This is backwards.  ids and gids are non-negative integers that can be
> represented in the type uid_t and gid_t, respectively.  All versions of
> POSIX require this.  Old versions of POSIX allowed uid_t and gid_t to
> be floating point, but didn't allow negative, fractional, infinity or
> NaN values.  Not so old versions of POSIX require uid_t and gid_t to
> be integer types, but still allow them to be sign.  Negative and values
> must not be created.  Unrepresentable values cannot be created of course,
> and should be rejected before they damage the password database.  uid_t
> and gid_t happened to be unsigned in FreeBSD, so negative values are
> unrepresentable so cannot be created.  pw is responsible for creating
> ids, so it should reject negative and other unrepresentable ids.  It
> has garbage code for both.
>=20
> 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 =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
Yes I know my patch is dirty, the whole pw(8) deserves a complete rewrite...

It was just a quick and dirty "fix" to try to solve what looks to me like an
abuse of bugs in pw(8) but it seems some people have scripts relying on it.
Which is why I was committed this given I broke the usage of this abuse.

I'll be more than happy to revert this "fix".

I added Devin in the CC as he maintains bsdconfig which rely on pw(8) accep=
ting
negative numbers. And he seems to have a strong feeling about having this
behaviour in pw(8).

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196514

Best regards,
Bapt

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

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

iEYEARECAAYFAlTEvbsACgkQ8kTtMUmk6EwlTACfZ2gR16oRyyRUPCmZJOGKvMBe
POYAoK9FGF9zfyNDaleoFjTl86FI+to2
=c+aZ
-----END PGP SIGNATURE-----

--C01fF7hLGvN0zd9s--



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