I was wondering if we could find a pointer (with an inode number) in
/proc/[pid]/fd but it turns out that we can't in this case because the file is closed, not held open.
I was able to attach to a running apache2 process with
gdb and cause a core dump
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 220.127.116.1180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) cd /root
Working directory /root.
(gdb) file /usr/sbin/apache2
Reading symbols from /usr/sbin/apache2...(no debugging symbols found)...done.
(gdb) !pidof apache2
28384 28383 28382
(gdb) attach 28384
Attaching to program: /usr/sbin/apache2, process 28384
[New LWP 28390]
[New LWP 28391]
[New LWP 28392]
[New LWP 28393]
[New LWP 28394]
[New LWP 28395]
[New LWP 28396]
[New LWP 28397]
[New LWP 28398]
[New LWP 28399]
[New LWP 28400]
[New LWP 28401]
[New LWP 28402]
[New LWP 28403]
[New LWP 28404]
[New LWP 28405]
[New LWP 28406]
[New LWP 28407]
[New LWP 28408]
[New LWP 28409]
[New LWP 28410]
[New LWP 28411]
[New LWP 28412]
[New LWP 28413]
[New LWP 28414]
[New LWP 28415]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fc166b8a394 in __libc_read (fd=7, buf=0x7ffd6c923473, nbytes=1) at ../sysdeps/unix/sysv/linux/read.c:27
27 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
warning: target file /proc/28384/cmdline contained unexpected null characters
Saved corefile core.28384
which contains some certificate data (e.g.
strings core.28384 | grep ocsp) but this didn't feel super-practical:
gdb failed to attach (maybe it mattered what syscall
apache2 was inside of or something?)
(2) the corefile is kind of enormous, I guess it contains all of the shared libraries and allocated-but-uninitialized memory
(3) I don't happen to know what data structures to look for (presumably you could learn more about symbols that you could read in the
apache2 process in order to find certificates in memory more expeditiously with
(4) this feels moderately dangerous on a production system, at least because users' incoming web connections might time out while a particular
apache2 is frozen by
(5) it might not be a good idea to randomly make spare copies of your private keys this way
(6) I think various security-oriented kernel patches and defaults will reduce your ability to attach a debugger to a running process
Arguably a better answer is to get Apache to behave better in response to
service apache2 graceful, or else to substitute
service apache2 restart for
service apache2 graceful in the command you're using to restart Apache (although this might also cause timeouts for live users).
But, the information in memory on your system, including certificates and key material, is ultimately accessible to you as the sysadmin if your OS hasn't been designed to hide it from you.