Re: 10.2-BETA1: pw(8) does not support pw useradd name -u 0
On 13 Jul 2015, at 19:10, Baptiste Daroussin b...@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@. 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
On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
On 13 Jul 2015, at 19:10, Baptiste Daroussin b...@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@. 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
On Tue, Jul 14, 2015 at 05:08:19PM +1000, Jan Mikkelsen wrote:
On 13 Jul 2015, at 19:10, Baptiste Daroussin b...@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@. 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=revisionrevision=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
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
Re: 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@. 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
