Re: getpwent bug?
2010/7/21 Dan Nelson dnel...@allantgroup.com:
In the last episode (Jul 21), Jens Rehsack said:
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name,
$grpass, $gid, $members ) = getgrent() ) { print $name is returned
more than once (No $dupchk{$name} comes here)\n if( $dupchk{$name}++
); print Dumper( [ $name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups
and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I don't know how to read perl's test output; what part of that report
failed, and how do you know it was due to getgrent returning duplicate
values?
Because I know the error picture - I've seen it on my FreeBSD box first.
I probably should add some diag() output for failing tests ...
BTW - I ran your one-liner above on a SLES 10.2 Linux box and a Solaris 10u7
box, and got duplicate entries where groups existed in both /etc/groups and
LDAP, just like on FreeBSD. I think you may be relying on behaviour that
getgrent doesn't guarantee on any OS.
But the duplicated entries I get are not duplicated in the source. I sent you my
/var/yp/groups file and the output of my one-liner.
I have no LDAP setup to try out, but in this case my workaround could be a good
idea.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I rate it as a bug - but I will write merge code for the duplicated entries.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 21), Jens Rehsack said:
On 07/16/10 18:13, Dan Nelson wrote:
Hi Dan,
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name,
$grpass, $gid, $members ) = getgrent() ) { print $name is returned
more than once (No $dupchk{$name} comes here)\n if( $dupchk{$name}++
); print Dumper( [ $name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups
and
my LDAP source, but that's expected.
You can see here
http://www.cpantesters.org/cpan/report/f5100ac6-9418-11df-9ebc-c4a68065c34d
the typical error picture. FreeBSD is the only system, where this error
occurs.
I don't know how to read perl's test output; what part of that report
failed, and how do you know it was due to getgrent returning duplicate
values?
BTW - I ran your one-liner above on a SLES 10.2 Linux box and a Solaris 10u7
box, and got duplicate entries where groups existed in both /etc/groups and
LDAP, just like on FreeBSD. I think you may be relying on behaviour that
getgrent doesn't guarantee on any OS.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Dan Nelson writes: In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in /your etc/passwd files. Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I had to develop a workaround for all other boxes anyway. Thank you very much, Jens Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: 2010/7/16 Dan Nelson dnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Can I do this without a full world rebuild? (I do not develop in FBSD actively). Otherwise I recommend (the test case was in OP) that someone with a separate test box tries it out and commit it etc. I don't think you need full world rebuild, just rebuilding world should do it. I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things.” (Robert A. Heinlein, 1973) pgpEMMcLPMPwi.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 08:36, Ashish SHUKLA wrote: Jens Rehsack writes: 2010/7/16 Dan Nelsondnel...@allantgroup.com: [...] Try the following patch: Thanks, I'll try it when I'm on my FreeBSD box. Great \o/ [...] I had to develop a workaround for all other boxes anyway. As a workaround you can use setpwent(3). I cached the entires - I rate setpwent as to dangerous. You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? You can take a look at http://cpansearch.perl.org/src/REHSACK/DBD-Sys-0.01_01/lib/DBD/Sys/Plugin/Unix/Users.pm Jens -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Q: Why UNIX geeks feel the need of a wife ? A: Since all UNIX geeks possess a large fortune db and according to Law of Jane Austen, It is a universal truth that a single man with a large fortune is in need of a wife.” (abbe, 2009) pgpuRlGdT7Don.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) | The setpassent() function accomplishes two purposes. First, it causes | getpwent() to ``rewind'' to the beginning of the database. Additionally, | if stayopen is non-zero, file descriptors are left open, significantly | speeding up subsequent accesses for all of the routines. (This latter | functionality is unnecessary for getpwent() as it does not close its file | descriptors by default.) | | It is dangerous for long-running programs to keep the file descriptors | open as the database will become out of date if it is updated while the | program is running. | | The setpwent() function is identical to setpassent() with an argument of | zero. ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. HTH -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Age is not an accomplishment, and youth is not a sin.” (Robert A. Heinlein, Methuselah's Children, 1958) pgpwVZo684yN8.pgp Description: PGP signature
Re: getpwent bug?
On 07/16/10 09:59, Ashish SHUKLA wrote: Jens Rehsack writes: On 07/16/10 09:12, Ashish SHUKLA wrote: Jens Rehsack writes: [...] I cached the entires - I rate setpwent as to dangerous. dangerous ? why ? Because it modifies something - and I might not know the source. getpwent(3) delivers entries from yp, too (or LDAP) etc. - and when I call setpwent(3) for such an entry, what happens then? Long explanation for: I do not know the consequences - and that's why I rate it dangerous as workaround. , an excerpt from getpwent(3) [...] ` I can't see anything which says about modifying NSS database. AFAIK none of the NSS routines allow you to write on database, you've to use the database specific method to modify the database. You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. Best regards and many, many thanks, Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Jens Rehsack writes: [...] You're absolutely right - I never took a deeper look, because I always was only interested to read the (user|group) data and expected setpwent to modify such an entry. Its UNIX :P A quick look into Stevens Advanced Programming in the UNIX environment could had enlighten myself. Sorry that I didn't RTFM carefully. No problems. -- Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0 freebsd.org!ashish | http://people.freebsd.org/~ashish/ “Software and cathedrals are much the same - first we build them, then we pray.” (anonymous) pgp1S6yBF1i4t.pgp Description: PGP signature
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said: 2010/7/16 Dan Nelson dnel...@allantgroup.com: In the last episode (Jul 16), Ashish SHUKLA said: Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. Was difficult for me to format the single liner ;) To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Could you please take a look to my other mail (getgrent related) - there seems another bug ... Do you have another one-liner that will reproduce it? A simple /usr/bin/getent group doesn't return dupes for me. Oddly enough, the *grent code doesn't use an internal counter, so the bug you found in endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy to read). Try the following patch: Can I do this without a full world rebuild? (I do not develop in FBSD actively). Assuming your test programs are dynamically linked, you only need to rebuld libc. Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
2010/7/16 Dan Nelsondnel...@allantgroup.com:
In the last episode (Jul 16), Ashish SHUKLA said:
Well, OP is also invoking 'endpwent()' after every 'getpwent()'
invocation which according to GNU/Linux's glibc and NetBSD's libc (as
OP mentioned) should rewind the position in passwd database to the
beginning.
Ah. I missed the endpwent calls.
Was difficult for me to format the single liner ;)
To me it definitely looks like a bug in FreeBSD's getpw*() family of
functions.
As tested using sysutils/lsof, in the following program in FreeBSD, the
descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but
position in database is never rewinded as shown in the output.
It looks like the *pwent functions keep an internal counter that
endpwent doesn't reset.
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that easy
to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
Best regards,
Jens
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
On 07/16/10 18:13, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
On 07/16/10 15:07, Dan Nelson wrote:
In the last episode (Jul 16), Jens Rehsack said:
Could you please take a look to my other mail (getgrent related) - there
seems another bug ...
Do you have another one-liner that will reproduce it? A simple
/usr/bin/getent group doesn't return dupes for me. Oddly enough, the
*grent code doesn't use an internal counter, so the bug you found in
endpwent doesn't exist in endgrent (afaik; the nsswitch code isn't that
easy to read).
Not really a one-liner:
perl -MData::Dumper -e 'setgrent; my %dupchk; while( my ( $name, $grpass,
$gid, $members ) = getgrent() ) { print $name is returned more than once
(No $dupchk{$name} comes here)\n if( $dupchk{$name}++ ); print Dumper( [
$name, $grpass, $gid, $members ] ) };'
setgrent() doesn't work here.
I ran that and got dupes for group entries that exist both in /etc/groups and
my LDAP source, but that's expected.
The dups I got are not duplicate:
$ less /var/yp/group
# $FreeBSD: src/etc/group,v 1.19.2.3 2002/06/30 17:57:17 des Exp $
#
wheel:*:0:root,trevor
staff:*:20:root
win32::1001:melanie,sarah
os2::1002:
dos::1003:
unix::1004:
music::1005:melanie,sarah
gamers::1006:
devel::1007:trevor
wwwdevel::15000:wwwglobal,trevor
All the rest (see attachment) are from /etc/group.
Jens
$VAR1 = [
'wheel',
'*',
0,
'root trevor mel'
];
$VAR1 = [
'daemon',
'*',
1,
''
];
$VAR1 = [
'kmem',
'*',
2,
''
];
$VAR1 = [
'sys',
'*',
3,
''
];
$VAR1 = [
'tty',
'*',
4,
''
];
$VAR1 = [
'operator',
'*',
5,
'root'
];
$VAR1 = [
'mail',
'*',
6,
''
];
$VAR1 = [
'bin',
'*',
7,
''
];
$VAR1 = [
'news',
'*',
8,
''
];
$VAR1 = [
'man',
'*',
9,
''
];
$VAR1 = [
'games',
'*',
13,
''
];
$VAR1 = [
'ftp',
'*',
14,
''
];
$VAR1 = [
'staff',
'*',
20,
''
];
$VAR1 = [
'sshd',
'*',
22,
''
];
$VAR1 = [
'smmsp',
'*',
25,
''
];
$VAR1 = [
'mailnull',
'*',
26,
''
];
$VAR1 = [
'guest',
'*',
31,
''
];
$VAR1 = [
'bind',
'*',
53,
''
];
$VAR1 = [
'proxy',
'*',
62,
''
];
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'_pflogd',
'*',
64,
''
];
$VAR1 = [
'_dhcp',
'*',
65,
''
];
$VAR1 = [
'uucp',
'*',
66,
''
];
$VAR1 = [
'dialer',
'*',
68,
''
];
$VAR1 = [
'network',
'*',
69,
''
];
$VAR1 = [
'audit',
'*',
77,
''
];
$VAR1 = [
'www',
'*',
80,
''
];
$VAR1 = [
'oper',
'*',
200,
'root trevor pgsql'
];
$VAR1 = [
'nogroup',
'*',
65533,
''
];
$VAR1 = [
'nobody',
'*',
65534,
''
];
$VAR1 = [
'messagebus',
'*',
556,
''
];
$VAR1 = [
'polkit',
'*',
559,
''
];
$VAR1 = [
'haldaemon',
'*',
560,
''
];
$VAR1 = [
'avahi',
'*',
558,
''
];
$VAR1 = [
'gdm',
'*',
92,
''
];
$VAR1 = [
'pgsql',
'*',
70,
''
];
smmsp is returned more than once (No 2 comes here)
$VAR1 = [
'smmsp',
'*',
25,
''
];
guest is returned more than once (No 2 comes here)
$VAR1 = [
'guest',
'*',
31,
''
];
authpf is returned more than once (No 2 comes here)
$VAR1 = [
'authpf',
'*',
63,
''
];
$VAR1 = [
'devel',
'',
1007,
'trevor'
];
tty is returned more than once (No 2 comes here)
$VAR1 = [
'tty',
'*',
4,
''
];
bin is returned
getpwent bug?
Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The correct output should be (taken from a NetBSD system): perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; Taking a look to http://www.cpantesters.org/distro/D/DBD-Sys.html#DBD-Sys-0.01, this issue is not limited to FreeBSD 7.3 - it occures on FreeBSD 7.2 and 8.0, too. I tried several perl versions on my box (perl5.8 from ports, perl5.10.1 from pkgsrc and the release candidate of perl5.12.0) - with the same result. Maybe someone could take a look? If I can provide additional information, please let me know. Best regards, Jens ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in your /etc/passwd files. The correct output should be (taken from a NetBSD system): perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; $VAR1 = [ 'root', '*', 0, 0, 0, '', 'Charlie ', '/root', '/bin/ksh', 0 ]; This output looks wrong, unless NetBSD has three identical root lines at the top of its passwd file. Taking a look to http://www.cpantesters.org/distro/D/DBD-Sys.html#DBD-Sys-0.01, this issue is not limited to FreeBSD 7.3 - it occures on FreeBSD 7.2 and 8.0, too. I see a bunch of failed FreeBSD test lines, but I don't see anything relating to getpwent or getreant in the test failure output. Just lines like Parse errors: Bad plan. You planned 16 tests but ran 12 -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: getpwent bug?
Dan Nelson writes:
In the last episode (Jul 15), Jens Rehsack said:
Hi all,
I detected an issue with getpwent on my FreeBSD test box:
perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e);
endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e =
getpwent(); print Dumper(\...@e); endpwent();'
$VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ];
$VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0
];
$VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes',
'/root', '/usr/sbin/nologin', 0 ];
I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD
7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010
r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64
The above output looks perfect, and should match the top three lines in your
/etc/passwd files.
Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation
which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned)
should rewind the position in passwd database to the beginning.
To me it definitely looks like a bug in FreeBSD's getpw*() family of
functions.
As tested using sysutils/lsof, in the following program in FreeBSD, the
descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but
position in database is never rewinded as shown in the output.
#v+
#include pwd.h
#include stdio.h
int
main()
{
struct passwd* pw;
int i;
char ch;
for(i = 0; i 3; i++)
{
printf(Doing getpwent(). Press any key to continue...);
while(getchar() != '\n');
pw = getpwent();
printf(%s:%d:%d\n, pw-pw_name, pw-pw_uid, pw-pw_gid);
endpwent();
}
}
#v-
Output on FreeBSD 8.1-RC2:
#v+
%./pwent
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
toor:0:0
Doing getpwent(). Press any key to continue...
daemon:1:1
#v-
Output on GNU/Linux:
#v+
% ./pwent
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
root:0:0
Doing getpwent(). Press any key to continue...
root:0:0
#v-
HTH
--
Ashish SHUKLA | GPG: F682 CDCC 39DC 0FEA E116 20B6 C746 CFA9 E74F A4B0
freebsd.org!ashish | http://people.freebsd.org/~ashish/
“How can I possibly put a new idea into your heads, if I do not first
remove your delusions?” (Robert A. Heinlein, Life-Line, 1939)
pgpSNaH90CVKQ.pgp
Description: PGP signature
Re: getpwent bug?
In the last episode (Jul 16), Ashish SHUKLA said: Dan Nelson writes: In the last episode (Jul 15), Jens Rehsack said: Hi all, I detected an issue with getpwent on my FreeBSD test box: perl -MData::Dumper -e 'my @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent(); @e = getpwent(); print Dumper(\...@e); endpwent();' $VAR1 = [ 'root', '', 0, 0, 0, '', 'Charlie ', '/root', '/bin/csh', 0 ]; $VAR1 = [ 'toor', '*', 0, 0, 0, '', 'Bourne-again Superuser', '/root', '', 0 ]; $VAR1 = [ 'daemon', '*', 1, 1, 0, '', 'Owner of many system processes', '/root', '/usr/sbin/nologin', 0 ]; I'm using FreeBSD waldorf.muppets.liwing.de 7.3-PRERELEASE FreeBSD 7.3-PRERELEASE #0: Fri Mar 12 11:31:18 UTC 2010 r...@waldorf.muppets.liwing.de:/usr/obj/usr/src/sys/WALDORF amd64 The above output looks perfect, and should match the top three lines in /your etc/passwd files. Well, OP is also invoking 'endpwent()' after every 'getpwent()' invocation which according to GNU/Linux's glibc and NetBSD's libc (as OP mentioned) should rewind the position in passwd database to the beginning. Ah. I missed the endpwent calls. To me it definitely looks like a bug in FreeBSD's getpw*() family of functions. As tested using sysutils/lsof, in the following program in FreeBSD, the descriptor corresponding to '/etc/pwd.db' is closed on endpwent(3) but position in database is never rewinded as shown in the output. It looks like the *pwent functions keep an internal counter that endpwent doesn't reset. Try the following patch: Index: gen/getpwent.c === --- gen/getpwent.c (revision 210157) +++ gen/getpwent.c (working copy) @@ -794,6 +794,7 @@ files_setpwent(void *retval, void *mdata, va_list (void)st-db-close(st-db); st-db = NULL; } + st-keynum = 0; break; default: break; -- Dan Nelson dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
