aboutsummaryrefslogtreecommitdiff
path: root/src/tutorial/basics.source
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-06-23 14:01:32 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-06-23 14:01:32 -0400
commit7eaf65451483a871056036e92e4f0fa0350b5504 (patch)
tree46042951765a3096e0dbfe1a4cd4ded7fe05d22f /src/tutorial/basics.source
parentd7da3ef08989691ffe13a914a839ea9e92b59a19 (diff)
downloadpostgresql-7eaf65451483a871056036e92e4f0fa0350b5504.tar.gz
postgresql-7eaf65451483a871056036e92e4f0fa0350b5504.zip
Don't assume GSSAPI result strings are null-terminated.
Our uses of gss_display_status() and gss_display_name() assumed that the gss_buffer_desc strings returned by those functions are null-terminated. It appears that they generally are, given the lack of field complaints up to now. However, the available documentation does not promise this, and some man pages for gss_display_status() show examples that rely on the gss_buffer_desc.length field instead of expecting null termination. Also, we now have a report that on some implementations, clang's address sanitizer is of the opinion that the byte after the specified length is undefined. Hence, change the code to rely on the length field instead. This might well be cosmetic rather than fixing any real bug, but it's hard to be sure, so back-patch to all supported branches. While here, also back-patch the v12 changes that made pg_GSS_error deal honestly with multiple messages available from gss_display_status. Per report from Sudheer H R. Discussion: https://postgr.es/m/5372B6D4-8276-42C0-B8FB-BD0918826FC3@tekenlight.com
Diffstat (limited to 'src/tutorial/basics.source')
0 files changed, 0 insertions, 0 deletions