Please also verify upstream branch backports:

release/2.30/master - May be required. Please check.
release/2.29/master - May be required. Please check.
release/2.28/master - May be required. Please check.

Verified with glibc tests: nss/tst-nss-db-endpwent, nss/tst-nss-db-endgrent.

Hi, DJ, thank you for providing the perfect future-release-note text.
Will you please review the suggested text since I had to modify it the tiniest bit to comply with the style guides?

I also got 1 question: is “db” a password storage type or some specific library (like BSD `db` library)? It’s about choosing between “db” and `db`.

Thank you in advance.



- - - suggested release note text - - -

.`glibc` no longer fails when getpwent() is called without calling setpwent()

Previously, calling getpwent() without calling setpwent() worked only once if one of the password providers was "db". The second call resulted in a `glibc` failure. This update fixes the problem. Calling endpwent() now correctly resets the internals to allow a new query without explicitly resetting it with setpwent().

Adding the string "db" to the "passwd" line in /etc/nsswitch.conf (other strings like "files", "dns", and "ldap" may be present, look at yours and see ;) causes the Berkeley DB backend to be used to lookup data.  In the context of this bug, it's the string in /etc/nsswitch.conf that I'm referring to, but it could be reworded either way.

And to clarify the "second time" phrase... the usual sequence of these calls is:

setpwent()
getpwent() returns first record
getpwent() returns second record
. . .
getpwent() returns "NO MORE DATA"
endpwent()

You can perform this *sequence* one time without the "setpwent()" call (but you shouldn't), but if you try to perform the sequence a second time, without calling setpwent() to restart it, it fails.

So it's not the "second call to getpwent()" it's the second time you do the sequence of getpwent() calls.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2020:1828

Hi DJ, I apologize for coming back to this release note only now. Will you please review the rewritten text so that I could publish this RN?
Thank you a lot in advance.


.`glibc` no longer fails when getpwent() is called without calling setpwent()

If your `/etc/nsswitch.conf` file pointed to the Berkeley DB (`db`) as a password provider, you could request data using getpwent() without first calling setpwent() only once. Repeated calls of getpwent() without first calling setpwent() caused `glibc` to fail because endpwent() could not reset the internals to allow a new query. This update fixes the problem. As a result, you can now request data using getpwent() without resetting queries with setpwent().

Suggestions:

Replace "as a password provider" with "password provider" - I think the grammar works better that way.

Replace "Repeated calls of getpwent()" with "Once you call endpwent(), further calls to getpwent()"

Replace "you can now request data" with "now, once you end one query with endpwent(), further calls to getpwent() will start a new query even if setpwent() is not called."

For background:  a typical query for all records is "call setpwent, then call getpwent a lot until it returns NULL, then call endpwent".  That iterates through every record.  If you want to iterate a second time, starting from the beginning, you're supposed to setpwent/lots of getpwent/endpwent again.  Omitting the setpwent at the beginning of the series of calls is technically wrong, but happens to work, except for the db backend.

The wording of the RN needs to be careful to differentiate between "call setpwent after getpwent" and "call setpwent after endpwent, so that getpwent starts from the beginning".  It's the "setpwent after endpwent" that's the key one.

Maybe "As a result, you can now start a new query after calling endpwent() without needing to call setpwent()"

Thank you, DJ, for great suggestions, especially for the last sentence, which is tricky.

Do you think providing the "proper" sequence of commands could clarify things for the customers? The sequence similar to the one you posted here before:

setpwent()
getpwent() returns first record
getpwent() returns second record
. . .
getpwent() returns "NO MORE DATA"
endpwent()


If you believe the text is enough, I'd publish the following (added your changes):

.`glibc` no longer fails when getpwent() is called without calling setpwent()

If your `/etc/nsswitch.conf` file pointed to the Berkeley DB (`db`) password provider, you could request data using getpwent() without first calling setpwent() only once. When you call endpwent(), further calls to getpwent() without first calling setpwent() caused `glibc` to fail because endpwent() could not reset the internals to allow a new query. This update fixes the problem. As a result, now, once you end one query with endpwent(), further calls to getpwent() will start a new query even if setpwent() is not called.

I think anyone reading that release note already has a general idea of how these functions work, it's more a matter of explaining the fix in terms of what they already know.  I think your latest text is fine.

Thank you a lot, DJ, for your time, your feedback is always very helpful.

Thank you for polishing it, Lenka! Yes, it's all correct, I only removed one definite article before `setpwent()`.