Date: Tue, 14 Jul 2015 17:08:19 +1000 From: Jan Mikkelsen <janm@transactionware.com> To: Baptiste Daroussin <bapt@FreeBSD.org> 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: <D30D2DAF-E00E-4ECE-857E-27E1B7EF8D41@transactionware.com> In-Reply-To: <20150713091006.GB37597@ivaldir.etoilebsd.net> References: <00BBEBAC-D7E2-4312-995B-93F7F0EDDD42@transactionware.com> <20150713083628.GA37597@ivaldir.etoilebsd.net> <20150713091006.GB37597@ivaldir.etoilebsd.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 =
"Bourne-again Superuser" -g wheel -o
>>>=20
>>> After 10.2-BETA1, the toor account is being added with UID 1001 =
instead of UID 0. This looks like a problem with line 754 in pw_user.c, =
which has 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.checkduplicate)
>>> errx(EX_DATAERR, "uid `%u' has already been =
allocated", 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 =
intentional?
>>=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, =
this is
> buggy, only one should be specified.
>=20
> Best regards,
> bapt
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 checking, not turn it on.
My guess is that this isn=E2=80=99t intentional either.
Also: The policy for auto-allocating group identifiers seems to have =
changed. For UIDs < 1000 the old pw allocated a GID the same as the UID. =
This pw allocates the next available above 1000. I can see an argument =
for both cases and I=E2=80=99ve changed our build scripts to deal with =
this but I=E2=80=99m curious: Was this intentional also?
Regards,
Jan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D30D2DAF-E00E-4ECE-857E-27E1B7EF8D41>