On 19.09.2023 03:54, Michael Paquier wrote:
One doubt that I have is if we shouldn't let X509_NAME_print_ex() be
as it is now, and not force a failure on the bio if this calls fails.
If malloc fails inside X509_NAME_print_ex, then we will be left with
empty port->peer_dn. Here is a gdb session showing this:
(gdb) b X509_NAME_print_ex
Breakpoint 1 at 0x7f539f6c0cf0
(gdb) c
Continuing.
Breakpoint 1, 0x00007f539f6c0cf0 in X509_NAME_print_ex () from
/lib/x86_64-linux-gnu/libcrypto.so.3
(gdb) bt
#0 0x00007f539f6c0cf0 in X509_NAME_print_ex () from
/lib/x86_64-linux-gnu/libcrypto.so.3
#1 0x000056026d2fbe8d in be_tls_open_server
(port=port@entry=0x56026ed5d730) at be-secure-openssl.c:635
#2 0x000056026d2eefa5 in secure_open_server
(port=port@entry=0x56026ed5d730) at be-secure.c:118
#3 0x000056026d3dc412 in ProcessStartupPacket
(port=port@entry=0x56026ed5d730, ssl_done=ssl_done@entry=false,
gss_done=gss_done@entry=false) at postmaster.c:2065
#4 0x000056026d3dcd8e in BackendInitialize
(port=port@entry=0x56026ed5d730) at postmaster.c:4377
#5 0x000056026d3def6a in BackendStartup
(port=port@entry=0x56026ed5d730) at postmaster.c:4155
#6 0x000056026d3df115 in ServerLoop () at postmaster.c:1781
#7 0x000056026d3e0645 in PostmasterMain (argc=argc@entry=20,
argv=argv@entry=0x56026ec5a0d0) at postmaster.c:1465
#8 0x000056026d2fcd7c in main (argc=20, argv=0x56026ec5a0d0) at main.c:198
(gdb) b malloc
Breakpoint 2 at 0x7f539eca5120: file ./malloc/malloc.c, line 3287.
(gdb) c
Continuing.
Breakpoint 2, __GI___libc_malloc (bytes=4) at ./malloc/malloc.c:3287
3287 ./malloc/malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_malloc (bytes=4) at ./malloc/malloc.c:3287
#1 0x00007f539f6f6e09 in BUF_MEM_grow_clean () from
/lib/x86_64-linux-gnu/libcrypto.so.3
#2 0x00007f539f6e4fb8 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3
#3 0x00007f539f6d22fb in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3
#4 0x00007f539f6d5c06 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3
#5 0x00007f539f6d5d37 in BIO_write () from
/lib/x86_64-linux-gnu/libcrypto.so.3
#6 0x00007f539f6bdb41 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3
#7 0x00007f539f6c0b7d in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3
#8 0x000056026d2fbe8d in be_tls_open_server
(port=port@entry=0x56026ed5d730) at be-secure-openssl.c:635
#9 0x000056026d2eefa5 in secure_open_server
(port=port@entry=0x56026ed5d730) at be-secure.c:118
#10 0x000056026d3dc412 in ProcessStartupPacket
(port=port@entry=0x56026ed5d730, ssl_done=ssl_done@entry=false,
gss_done=gss_done@entry=false) at postmaster.c:2065
#11 0x000056026d3dcd8e in BackendInitialize
(port=port@entry=0x56026ed5d730) at postmaster.c:4377
#12 0x000056026d3def6a in BackendStartup
(port=port@entry=0x56026ed5d730) at postmaster.c:4155
#13 0x000056026d3df115 in ServerLoop () at postmaster.c:1781
#14 0x000056026d3e0645 in PostmasterMain (argc=argc@entry=20,
argv=argv@entry=0x56026ec5a0d0) at postmaster.c:1465
#15 0x000056026d2fcd7c in main (argc=20, argv=0x56026ec5a0d0) at main.c:198
(gdb) return 0
Make __GI___libc_malloc return now? (y or n) y
#0 0x00007f539f6f6e09 in BUF_MEM_grow_clean () from
/lib/x86_64-linux-gnu/libcrypto.so.3
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) c
Continuing.
And in the server log we see:
DEBUG: SSL connection from DN:"" CN:"ssltestuser"
While in the normal case we get:
DEBUG: SSL connection from DN:"CN=ssltestuser" CN:"ssltestuser"\
Probably we shouldn't ignore the error from X509_NAME_print_ex?
--
Sergey Shinderuk https://postgrespro.com/
