Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Jul 2015 14:24:36 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Jan Mikkelsen <janm@transactionware.com>
Cc:        FreeBSD Stable Mailing List <freebsd-stable@freebsd.org>
Subject:   Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"
Message-ID:  <20150714122434.GI37597@ivaldir.etoilebsd.net>
In-Reply-To: <D30D2DAF-E00E-4ECE-857E-27E1B7EF8D41@transactionware.com>
References:  <00BBEBAC-D7E2-4312-995B-93F7F0EDDD42@transactionware.com> <20150713083628.GA37597@ivaldir.etoilebsd.net> <20150713091006.GB37597@ivaldir.etoilebsd.net> <D30D2DAF-E00E-4ECE-857E-27E1B7EF8D41@transactionware.com>

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

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

On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
>=20
> > On 13 Jul 2015, at 19:10, Baptiste Daroussin <bapt@FreeBSD.org> wrote:
> >=20
> > On Mon, Jul 13, 2015 at 10:36:28AM +0200, Baptiste Daroussin wrote:
> >> On Mon, Jul 13, 2015 at 04:57:32PM +1000, Jan Mikkelsen wrote:
> >>> Hi,
> >>>=20
> >>> In our system build scripts we have this command:
> >>>=20
> >>> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c "Bou=
rne-again Superuser" -g wheel -o
> >>>=20
> >>> After 10.2-BETA1, the toor account is being added with UID 1001 inste=
ad of UID 0. This looks like a problem with line 754 in pw_user.c, which ha=
s this test:
> >>>=20
> >>>        /*
> >>>         * Check the given uid, if any
> >>>         */
> >>>        if (id > 0) {
> >>>                uid =3D (uid_t) id;
> >>>=20
> >>>                if ((pwd =3D GETPWUID(uid)) !=3D NULL && conf.checkdup=
licate)
> >>>                        errx(EX_DATAERR, "uid `%u' has already been al=
located", pwd->pw_uid);
> >>>        } else {
> >>>                struct bitmap   bm;
> >>>=20
> >>>=20
> >>> The (id > 0) test should probably be (id >=3D 0) to allow =E2=80=9C-u=
 0=E2=80=9D to be passed on the command line.
> >>>=20
> >>> This change is from r285092 by bapt@. Was this change in behaviour in=
tentional?
> >>=20
> >> Nope, I'll fix asap
> >>=20
> >> Thanks for reporting
> >>=20
> >> Best regards,
> >> Bapt
> >=20
> > Fixed in head, will be merged soon in stable, I also added a regression=
 test
> > about this.
> >=20
> > Please note that you do add -g 0 and -g wheel in your command line, thi=
s is
> > buggy, only one should be specified.
> >=20
> > Best regards,
> > bapt
>=20
> The next problem is that the meaning of the -o option seems to have been =
reversed. Setting -o sets conf.checkduplicate to true, which is then tested=
 in the code fragment above. Setting -o is meant to prevent duplicate check=
ing, not turn it on.
>=20
> My guess is that this isn=E2=80=99t intentional either.
>=20
> Also: The policy for auto-allocating group identifiers seems to have chan=
ged. For UIDs < 1000 the old pw allocated a GID the same as the UID. This p=
w allocates the next available above 1000. I can see an argument for both c=
ases and I=E2=80=99ve changed our build scripts to deal with this but I=E2=
=80=99m curious: Was this intentional also?
>=20
> Regards,
>=20
All fixes has been merged:
https://svnweb.freebsd.org/base?view=3Drevision&revision=3D285536

Do not hesitate to report other regressions if you do find any more.

Thank you very much,
Bapt

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

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

iEYEARECAAYFAlWk/4IACgkQ8kTtMUmk6EzEiwCgt7O6PxqLtXG1nQaUJiqRzJyR
uFIAoJ2WjcBvyP9jI8RiMnLI+rfErodx
=Hf+W
-----END PGP SIGNATURE-----

--d6d1KVhp94hk3Jrm--



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