Bug 665

Summary: script running under sudo can't recursively call itself in background
Product: Sudo Reporter: steve.williams
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED FIXED    
Severity: normal    
Priority: normal    
Version: 1.8.11   
Hardware: Sun   
OS: Solaris 2.x   
Attachments: screen output from test script

Description steve.williams 2014-09-26 07:06:34 MDT
Created attachment 429 [details]
screen output from test script

When a script is run via sudo it can't recursively call itself in the background. For example, test.ksh takes 1 arguement (start), should echo
start
start2 and touch file in /var/tmp.

but the "$0 start2 &" doesn't appear to get run (there are no errors):

#!/bin/ksh
if [[ $1 == "start" ]]
 then
      echo $1
      $0 start2 &
 else
      echo $1
      touch /var/tmp/start2
fi

Running it without sudo works ok, as does removing the "&" from line 5 and running with sudo.

We have just upgraded from SMCsudo to TCMsudo and the script has worked previously on SMCsudo.

The server is a Sun/Oracle T4-4 (sparc) running Solaris 10, TMCsudo1.8.11.
Comment 1 Todd C. Miller 2014-09-26 15:15:55 MDT
This sounds like a race condition between the parent script and the child.  The script works fine for me on a single-CPU instance in a VM either normally or in a pseudo-tty (use_pty or log_output in sudoers).  However, if I  add a sleep that guarantees that the foreground process exits before the background one is done I see what you describe when the command runs in a pty.

What happens is that the pty that the command was using goes away after the foreground command has exited.  Any child of the command receives SIGHUP from the kernel when this happens which is why you don't see the background job finish.  You can use nohup to prevent the background job from being killed by SIGHUP.  It will also store the output in the file nohup.out since the command doesn't have access to a tty after the parent exits.

If you don't have use_pty or one of the log_* options set in sudoers then something else may be going on.
Comment 2 Todd C. Miller 2018-01-16 14:25:51 MST
This works as expected with sudo 1.8.22 both with and without log_output.

sol10 [~] % ls -l /var/tmp/start2
/var/tmp/start2: No such file or directory
sol10 [~] % sudo /var/tmp/sudotest start
start
start2
sol10 [~] % ls -l /var/tmp/start2
-rw-r--r--   1 root     root           0 Jan 16 14:24 /var/tmp/start2

If the problem still occurs with sudo 1.8.22, please re-open the bug.