I am trying to implement sudo session logging across our Linux infrastructure, and we are currently still using Ubuntu 20.04 with sudo 1.8.31 installed.

I've hit a situation that has caused me to pause the rollout of this project.

I have enabled sudo IO via adding this to my sudoers file:
Defaults maxseq=5000
Defaults log_output
Defaults!/usr/bin/sudoreplay !log_output
Defaults!/sbin/reboot !log_output

Having enabled this on my workstation to test I was working on another project and needed to use 'sudo' to quickly edit /etc/audit/rules.d/audit.rules multiple times for small changes, backgrounding the vim process while I restarted the auditd service. I then went to go get and eat lunch, and upon my return I noted that I had been disconnected from the host I had been working on. Our monitoring system noted that my workstation had crashed due to running out of disk space on '/'.

What I found after recovering from this was the 'timing' file from the 'sudo vi...' command had filled up the disk, which was on a 120GB partition with 90GB free at the time the command had been ran. 

Steps to easily reproduce:
1) login as regular user
2) sudo vi(m) anything
3) control-z to background the vi(m) process
4) log out of controlling PTY

At this point the 'sudo vi ...' process run by the login user and the root-owned processes that get started are taking up a LOT of CPU (100% of one core at least) and filling up the disk with the 'timing' information that is kept in the hashed sudoreplay directory, here is an example:

root@myhostname:/var/log/sudo-io/00/00/2T# ls -lh
total 4.5G
-rw------- 1 root root  112 Jul 24 09:41 log
-rw------- 1 root root    0 Jul 24 09:41 stderr
-rw------- 1 root root    0 Jul 24 09:41 stdout
-rw------- 1 root root 4.5G Jul 24 10:43 timing
-rw------- 1 root root    0 Jul 24 09:41 ttyout
first 16 lines of timing file:
4 0.061682265 39
4 0.000225201 26
4 0.000026700 7
4 0.002592320 68
4 0.000210602 21
4 0.006051745 13
4 0.000121801 14
4 0.000139601 4
4 0.000028600 14
4 0.000994408 1899
4 6.349738439 76
7 0.000023200 TSTP
7 33.921194660 CONT
7 0.000076700 TTOU
7 0.013490302 CONT
7 0.000215202 TTOU

It *seems* like once the vim process gets orphaned, sudo goes into a loop of reading from stdin/stderr that's constantly trying to "foreground" the process but it immediately goes back into "background".

I can reproduce this with both vim and sudoedit/sudo -e.

Besides the block needed to enable sudo-io, our sudoers file is not much more than stock Ubuntu, with just:
# Path and Editor
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults    editor = /usr/bin/vi:/usr/bin/vim, !env_editor


I haven't been able to find anyone else reporting this issue or anything like it, nor any documentation on the subject ... which I find odd as it is so easy to reproduce and it's a pretty big issue (for me at least!).

Any help or links to RTFM would be greatly appreciated.

Regards,
Brian Mendenhall
wyndl.jones@gmail.com