Back to bug 1747502
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Red Hat Bugzilla | 2019-08-30 15:54:04 UTC | Pool ID | sst_platform_tools_rhel_8 | |
| Florian Weimer | 2019-08-30 15:54:55 UTC | Link ID | Sourceware 24696 Sourceware 24695 | |
| Carlos O'Donell | 2019-10-01 16:42:49 UTC | Keywords | Triaged | |
| Carlos O'Donell | 2019-10-07 04:48:33 UTC | Blocks | 1746918 | |
| Florian Weimer | 2019-10-22 14:10:48 UTC | Status | NEW | ASSIGNED |
| Sergey Kolosov | 2019-10-24 06:56:16 UTC | CC | skolosov | |
| Carlos O'Donell | 2019-10-24 13:54:28 UTC | Assignee | glibc-bugzilla | dj |
| DJ Delorie | 2019-11-08 20:24:21 UTC | Doc Text | Calling getpwent() without calling setpwent() happens to work - but only once, if one of the password providers is "db". Doing this a second time resulted in a crash. This is now fixed, such that calling endpwent() correctly resets the internals to allow a new query without explicitly resetting it with setpwent() | |
| Doc Type | If docs needed, set a value | Bug Fix | ||
| Carlos O'Donell | 2019-11-15 18:24:24 UTC | Status | ASSIGNED | MODIFIED |
| Fixed In Version | glibc-2.28-84 | |||
| errata-xmlrpc | 2019-11-15 20:28:09 UTC | Status | MODIFIED | ON_QA |
| Sergey Kolosov | 2020-02-21 07:42:34 UTC | Status | ON_QA | VERIFIED |
| Oss Tikhomirova | 2020-03-20 18:20:16 UTC | CC | otikhomi | |
| Docs Contact | otikhomi | |||
| Oss Tikhomirova | 2020-03-23 13:48:44 UTC | Flags | needinfo?(dj) | |
| DJ Delorie | 2020-03-23 15:59:42 UTC | Flags | needinfo?(dj) | |
| errata-xmlrpc | 2020-04-28 00:32:12 UTC | Status | VERIFIED | RELEASE_PENDING |
| Oss Tikhomirova | 2020-04-28 10:50:42 UTC | Doc Text | Calling getpwent() without calling setpwent() happens to work - but only once, if one of the password providers is "db". Doing this a second time resulted in a crash. This is now fixed, such that calling endpwent() correctly resets the internals to allow a new query without explicitly resetting it with setpwent() | .`glibc` no longer fails when getpwent() is called without calling setpwent() Calling getpwent() without calling setpwent() happens to work - but only once, if one of the password providers is "db". Doing this a second time resulted in a crash. This is now fixed, such that calling endpwent() correctly resets the internals to allow a new query without explicitly resetting it with setpwent() |
| errata-xmlrpc | 2020-04-28 16:50:14 UTC | Status | RELEASE_PENDING | CLOSED |
| Resolution | --- | ERRATA | ||
| Last Closed | 2020-04-28 16:50:14 UTC | |||
| errata-xmlrpc | 2020-04-28 16:50:51 UTC | Link ID | Red Hat Product Errata RHSA-2020:1828 | |
| Oss Tikhomirova | 2020-05-14 19:39:15 UTC | Flags | needinfo?(dj) | |
| DJ Delorie | 2020-05-14 20:58:38 UTC | Flags | needinfo?(dj) | |
| Oss Tikhomirova | 2020-05-15 20:12:44 UTC | Doc Text | .`glibc` no longer fails when getpwent() is called without calling setpwent() Calling getpwent() without calling setpwent() happens to work - but only once, if one of the password providers is "db". Doing this a second time resulted in a crash. This is now fixed, such that calling endpwent() correctly resets the internals to allow a new query without explicitly resetting it with setpwent() | .`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. |
| Flags | needinfo?(dj) | |||
| DJ Delorie | 2020-05-15 20:50:34 UTC | Flags | needinfo?(dj) | |
| Oss Tikhomirova | 2020-05-18 11:34:49 UTC | Doc Text | .`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. | .`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, once you end one query with endpwent(), further calls to getpwent() will start a new query even if setpwent() is not called. |
| Oss Tikhomirova | 2020-05-18 11:53:05 UTC | Doc Text | .`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, once you end one query with endpwent(), further calls to getpwent() will start a new query even if setpwent() is not called. | .`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 called 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, after you end one query with endpwent(), further calls to getpwent() will start a new query even if you do not call setpwent(). |
| Lenka Špačková | 2020-05-20 13:50:59 UTC | Doc Text | .`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 called 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, after you end one query with endpwent(), further calls to getpwent() will start a new query even if you do not call setpwent(). | .`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 the `getpwent()` function without first calling the `setpwent()` only once. When you called the `endpwent()` function, 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, after you end one query with `endpwent()`, further calls to `getpwent()` will start a new query even if you do not call `setpwent()`. |
| Oss Tikhomirova | 2020-05-20 13:59:30 UTC | Doc Text | .`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 the `getpwent()` function without first calling the `setpwent()` only once. When you called the `endpwent()` function, 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, after you end one query with `endpwent()`, further calls to `getpwent()` will start a new query even if you do not call `setpwent()`. | .`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 the `getpwent()` function without first calling `setpwent()` only once. When you called the `endpwent()` function, 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, after you end one query with `endpwent()`, further calls to `getpwent()` will start a new query even if you do not call `setpwent()`. |
| Red Hat One Jira (issues.redhat.com) | 2020-12-20 08:21:26 UTC | Link ID | Red Hat Issue Tracker - Private RHELPLAN-28029 | |
| Pavel Najman | 2021-09-17 12:19:35 UTC | Pool ID | sst_platform_tools_rhel_8 | sst_pt_gcc_glibc_rhel_8 |
| Mark O'Brien | 2023-07-18 14:30:35 UTC | Pool ID | sst_pt_glibc_rhel_8 | sst_pt_libraries_rhel_8 |
Back to bug 1747502