pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix timing-dependent failure in GSSAPI data transmission. 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d053a879bb360fb72c46de2a013e741d3f7c9e8d Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 ++++++++++++++++----------------- src/interfaces/libpq/fe-secure-gssapi.c | 52 +++++++++++++--------------- src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 56 insertions(+), 60 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/85eb771854839608a89b49a9511b67a4c61fd789 Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 ++++++++++++++++----------------- src/interfaces/libpq/fe-secure-gssapi.c | 52 +++++++++++++--------------- src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 56 insertions(+), 60 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a50053777e95b077b2d8a43d8adfa9d396dd3994 Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 +++++++++++++++---------------- src/interfaces/libpq/fe-secure-gssapi.c | 62 +++++++++++++++------------------ src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 61 insertions(+), 65 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8f23e6a45009424ed6e01d95d066955e2b38cfc4 Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 +++++++++++++++---------------- src/interfaces/libpq/fe-secure-gssapi.c | 62 +++++++++++++++------------------ src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 61 insertions(+), 65 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5abdfd88fa771a48bcdbf6c62ceab1cc8d9dd804 Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 +++++++++++++++---------------- src/interfaces/libpq/fe-secure-gssapi.c | 62 +++++++++++++++------------------ src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 61 insertions(+), 65 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix timing-dependent failure in GSSAPI data transmission. @ 2023-11-23 18:30 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-23 18:30 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix timing-dependent failure in GSSAPI data transmission. When using GSSAPI encryption in non-blocking mode, libpq sometimes failed with "GSSAPI caller failed to retransmit all data needing to be retried". The cause is that pqPutMsgEnd rounds its transmit request down to an even multiple of 8K, and sometimes that can lead to not requesting a write of data that was requested to be written (but reported as not written) earlier. That can upset pg_GSS_write's logic for dealing with not-yet-written data, since it's possible the data in question had already been incorporated into an encrypted packet that we weren't able to send during the previous call. We could fix this with a one-or-two-line hack to disable pqPutMsgEnd's round-down behavior, but that seems like making the caller work around a behavior that pg_GSS_write shouldn't expose in this way. Instead, adjust pg_GSS_write to never report a partial write: it either reports a complete write, or reflects the failure of the lower-level pqsecure_raw_write call. The requirement still exists for the caller to present at least as much data as on the previous call, but with the caller-visible write start point not moving there is no temptation for it to present less. We lose some ability to reclaim buffer space early, but I doubt that that will make much difference in practice. This also gets rid of a rather dubious assumption that "any interesting failure condition (from pqsecure_raw_write) will recur on the next try". We've not seen failure reports traceable to that, but I've never trusted it particularly and am glad to remove it. Make the same adjustments to the equivalent backend routine be_gssapi_write(). It is probable that there's no bug on the backend side, since we don't have a notion of nonblock mode there; but we should keep the logic the same to ease future maintenance. Per bug #18210 from Lars Kanis. Back-patch to all supported branches. Discussion: https://postgr.es/m/18210-4c6d0b14627f2eb8@postgresql.org Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/18fad508b783654e516898d2246a8ac3c98e47e0 Modified Files -------------- src/backend/libpq/be-secure-gssapi.c | 60 +++++++++++++++---------------- src/interfaces/libpq/fe-secure-gssapi.c | 62 +++++++++++++++------------------ src/interfaces/libpq/libpq-int.h | 4 +-- 3 files changed, 61 insertions(+), 65 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2023-11-23 18:30 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us> 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us> 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us> 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us> 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us> 2023-11-23 18:30 pgsql: Fix timing-dependent failure in GSSAPI data transmission. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox