freebsd stable - Jul 2015 - 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

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,
> > 
> > In our system build scripts we have this command:
> > 
> > /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c
"Bourne-again Superuser" -g wheel -o
> > 
> > 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:
> > 
> >         /*
> >          * Check the given uid, if any
> >          */
> >         if (id > 0) {
> >                 uid = (uid_t) id;
> > 
> >                 if ((pwd = GETPWUID(uid)) != NULL &&
conf.checkduplicate)
> >                         errx(EX_DATAERR, "uid `%u' has
already been allocated", pwd->pw_uid);
> >         } else {
> >                 struct bitmap   bm;
> > 
> > 
> > The (id > 0) test should probably be (id >= 0) to allow ?-u 0?
to be passed on the command line.
> > 
> > This change is from r285092 by bapt at . Was this change in behaviour
intentional?
> 
> Nope, I'll fix asap
> 
> Thanks for reporting
> 
> Best regards,
> Bapt
Fixed in head, will be merged soon in stable, I also added a regression test
about this.

Please note that you do add -g 0 and -g wheel in your command line, this is
buggy, only one should be specified.

Best regards,
bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150713/30bb10ee/attachment.bin>

> On 13 Jul 2015, at 19:10, Baptiste Daroussin <bapt at FreeBSD.org>
wrote:
> 
> 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,
>>> 
>>> In our system build scripts we have this command:
>>> 
>>> /usr/sbin/pw -V $d useradd toor -u 0 -g 0 -d /root -s /bin/sh -c
"Bourne-again Superuser" -g wheel -o
>>> 
>>> 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:
>>> 
>>>        /*
>>>         * Check the given uid, if any
>>>         */
>>>        if (id > 0) {
>>>                uid = (uid_t) id;
>>> 
>>>                if ((pwd = GETPWUID(uid)) != NULL &&
conf.checkduplicate)
>>>                        errx(EX_DATAERR, "uid `%u' has
already been allocated", pwd->pw_uid);
>>>        } else {
>>>                struct bitmap   bm;
>>> 
>>> 
>>> The (id > 0) test should probably be (id >= 0) to allow ?-u
0? to be passed on the command line.
>>> 
>>> This change is from r285092 by bapt at . Was this change in
behaviour intentional?
>> 
>> Nope, I'll fix asap
>> 
>> Thanks for reporting
>> 
>> Best regards,
>> Bapt
> 
> Fixed in head, will be merged soon in stable, I also added a regression
test
> about this.
> 
> Please note that you do add -g 0 and -g wheel in your command line, this is
> buggy, only one should be specified.
> 
> 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?t 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?ve changed our build scripts to deal with this but I?m curious: Was this
intentional also?

Regards,

Jan.