Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

2015-07-14 Thread Baptiste Daroussin
On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
> 
> > On 13 Jul 2015, at 19:10, Baptiste Daroussin  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@. 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,
> 
All fixes has been merged:
https://svnweb.freebsd.org/base?view=revision&revision=285536

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

Thank you very much,
Bapt


pgpKAZHfAKRVC.pgp
Description: PGP signature


Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

2015-07-14 Thread Baptiste Daroussin
On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
> 
> > On 13 Jul 2015, at 19:10, Baptiste Daroussin  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@. 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?
> 

Both has been fixed head already I do plan to merge them later today so they
will be in BETA2

Best regards,
Bapt


pgp6XSYUz1o2z.pgp
Description: PGP signature


Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

2015-07-14 Thread Jan Mikkelsen

> On 13 Jul 2015, at 19:10, Baptiste Daroussin  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@. 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.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

2015-07-13 Thread Baptiste Daroussin
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@. 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


pgpXGvYnqU7zZ.pgp
Description: PGP signature


Re: 10.2-BETA1: pw(8) does not support "pw useradd name -u 0"

2015-07-13 Thread Baptiste Daroussin
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@. Was this change in behaviour 
> intentional?

Nope, I'll fix asap

Thanks for reporting

Best regards,
Bapt


pgpDnNIUX4Hk0.pgp
Description: PGP signature