Zombie process using sudo 1.8

[chandrasekhar1996]

I am using Sudo version 1.8.23 on Amazon Linux 2

I am using a pam module created using cgo (sample pam module for testing: pam-ysshca). I have enabled debug logs in /etc/sudo.conf using Debug sudo /var/log/sudo_debug all@debug .

Script I am running is :

#!/bin/bash

n=1
m=10
while ((n < m))
do
  mkdir -p /tmp/$n
  strace -D -ffftt -o /tmp/$n/strace sudo echo $n &
  n=$(( n + 1 ))
  sleep 1
done

I get zombie process on executing this script using sudo nohup test.sh & .
What I am noticing is that

1. sudo sets up the temporary signal handler
2. executes the echo command
3. echo command exits successfully before the main signal handler is setup by sudo
4. the main pid executing sudo command never receives the SIGCHLD

This is reproducible everytime sudo debug logs are turned on since I think time is also being used to print log statements before the actual signal handler is setup/

When debug logs is turned off, this happens 1 in 100s of execution because most of the time the new signal handler gets initialized (rt_sigaction for SIGCHLD) before the echo command exits.

Is this expected behavior that if SIGCHLD is received before the new signal handler is setup then it will lead to zombie processes.

[millert]

That version of sudo is 5 years old, can you try a more recent version? I can't reproduce this with the current version of sudo using your test script. However, even in 1.8.23, SIGCHLD is blocked until after the main signal handler is installed so there should not be a race condition. There was a race condition that could result in a hang when sudo is executed by a process where the SIGCHLD handler is set to SIG_IGN but that doesn't sound like what you are describing.

[chandrasekhar1996]

The pam module I am using is written in Golang, so it creates multiple threads when it initializes. So these threads don't have the signal masked and hence I think the signal is sent to the first signal handler when one of these threads receive the signal.

Follow up question, why is signal handler setup for SIGCHLD if it is ignored here

sudo/src/exec.c

Line 325 in cb01b90

case SIGCHLD:

?

But I am thinking even if we don't have that initial signal handler for SIGCHLD then it would be ignored and we would run into the same issue

[millert]

That is just for when sudo is killed before it executes a command. There really shouldn't be any children at that point.

[millert]

I installed pam-ysshca and the only zombies I see are from strace, not sudo itself when using the latest sudo sources. Can you reproduce this problem with the latest version of sudo? If so, please provide ps output that shows the zombie processes and their parents.