Bug 482

Summary: Sudo 1.7.4 - 1.8.0 problem
Product: Sudo Reporter: Radu Mihaescu <radu.d.mihaescu>
Component: SudoAssignee: Todd C. Miller <Todd.Miller>
Status: RESOLVED INVALID    
Severity: high CC: victor.marginean
Priority: low    
Version: 1.8.0   
Hardware: Sun   
OS: Other   

Description Radu Mihaescu 2011-03-11 08:06:51 MST
Hello,

I have a problem since I tried to upgrade Sudo version on my Solaris 10 machines from 1.7.2p6 to 1.7.4p5 and still at 1.8.0 release.
When I launch any script using Sudo the application is starting, but the starting sudo process is hanging:

2ksh# ps -ef |grep bsscomm
    root 21332  1168   0 14:50:50 ?   0:00 sudo ...bsscomm/bin/bsscomm .ip
    user 21350 21332   0 14:50:51 ?   0:03 ../bsscomm/bin/bsscomm .ip
    root 21296  1168   0 14:50:48 ?   0:00 sudo ../bsscomm/bin/bsscomm
    user 21315 21296   0 14:50:49 ?   0:02 ../bsscomm/bin/bsscomm

I launch the script with "user" and the habgiging process is a root process. Because of this process being hanged the application is not working properly.
Even though I set the option NOPASSWD in sudoers, I suspect that the script could be still waiting for the password.

Thanks for your help !
Comment 1 Todd C. Miller 2011-03-11 10:52:44 MST
In sudo 1.7.3 and higher, which sudo runs a command there is a root-owned process that waits until the command completes, at which point sudo will close the PAM session.

Is the command you are running actually hanging (never completing) or are you just seeing the sudo processes that are waiting for the command to finish?

Can you give me any more details about this script?
Comment 2 Todd C. Miller 2011-03-11 11:16:50 MST
Also, there was a bug in sudo 1.7.3-1.7.4 where sudo could miss the notification that the child process completed.  This could explain what you are seeing, but as far as I know, that was fixed in sudo 1.7.5 and 1.8.0.
Comment 3 Radu Mihaescu 2011-03-14 04:38:51 MDT
(In reply to comment #2)
> Also, there was a bug in sudo 1.7.3-1.7.4 where sudo could miss the
> notification that the child process completed.  This could explain what
> you are seeing, but as far as I know, that was fixed in sudo 1.7.5 and
> 1.8.0.

The last version that worked fine for me was 1.7.2.
Then I upgraded to 1.7.4p4, 1.7.4p5 and 1.8.0 and the problem persists.
You can consider an example just a simple script with a print and a 10 seconds wait. 
exec sudo script ->will start the script, but the father process won't stop after it starts the desired application (script).
Comment 4 Todd C. Miller 2011-03-16 13:14:41 MDT
(In reply to comment #3)
> The last version that worked fine for me was 1.7.2.
> Then I upgraded to 1.7.4p4, 1.7.4p5 and 1.8.0 and the problem persists.
> You can consider an example just a simple script with a print and a 10
> seconds wait. 
> exec sudo script ->will start the script, but the father process won't
> stop after it starts the desired application (script).

I'm having trouble reproducing your problem so I want to make sure we are talking about thesame thing.  Given the following two scripts:

/tmp/sudotest:

#!/bin/sh

echo running sudotest2
exec /usr/local/bin/sudo /tmp/sudotest2

and /tmp/sudotest2:

#!/bin/sh

echo in sudotest2
sleep 10
exit 0

If I run /tmp/sudotest it exits just fine after 10 seconds.  During that time, the sudo process is also running, but that is expected behavior--it closes the PAM session once sudotest2 is finished.  E.g.

sol10 [~] % uname -a
SunOS sol10 5.10 Generic_141445-09 i86pc i386 i86pc
sol10 [~] % /usr/bin/time /tmp/sudotest
running sudotest2
in sudotest2

real       10.0
user        0.0
sys         0.0
sol10 [~] % ps -ef | grep sudo
 millert  5693 23313   0 13:14:20 pts/1       0:00 grep sudo

Are you seeing cases where the script that does the exec hangs after running the command via sudo?
Comment 5 Radu Mihaescu 2011-03-18 10:06:32 MDT
(In reply to comment #4)
> (In reply to comment #3)
> > The last version that worked fine for me was 1.7.2.
> > Then I upgraded to 1.7.4p4, 1.7.4p5 and 1.8.0 and the problem persists.
> > You can consider an example just a simple script with a print and a 10
> > seconds wait. 
> > exec sudo script ->will start the script, but the father process won't
> > stop after it starts the desired application (script).
> 
> I'm having trouble reproducing your problem so I want to make sure we
> are talking about thesame thing.  Given the following two scripts:
> 
> /tmp/sudotest:
> 
> #!/bin/sh
> 
> echo running sudotest2
> exec /usr/local/bin/sudo /tmp/sudotest2
> 
> and /tmp/sudotest2:
> 
> #!/bin/sh
> 
> echo in sudotest2
> sleep 10
> exit 0
> 
> If I run /tmp/sudotest it exits just fine after 10 seconds.  During
> that time, the sudo process is also running, but that is expected
> behavior--it closes the PAM session once sudotest2 is finished.  E.g.
> 
> sol10 [~] % uname -a
> SunOS sol10 5.10 Generic_141445-09 i86pc i386 i86pc
> sol10 [~] % /usr/bin/time /tmp/sudotest
> running sudotest2
> in sudotest2
> 
> real       10.0
> user        0.0
> sys         0.0
> sol10 [~] % ps -ef | grep sudo
>  millert  5693 23313   0 13:14:20 pts/1       0:00 grep sudo
> 
> Are you seeing cases where the script that does the exec hangs after
> running the command via sudo?

Hello,

I made the test with these scripts in 3 different Sudo versions:

1. Sudo 1.7.2p6
I run sudotest script as the working user, other than root (with 20 sec wait).
root@hrean:/root 
120ksh# ps -ef |grep sudo
    root 11355 24744   0 15:58:32 pts/8       0:00 grep sudo
    root 11341  2929   0 15:58:28 pts/9       0:00 /bin/sh /tmp/sudotest2
In these 20 seconds this ps command will show only sudotest2 process.

2. Sudo 1.7.4p5
I run sudotest script and during the 20 seconds wait I get this ps output:
root@hrean:/root 
171ksh# ps -ef |grep sudo
    root 12439 18415   0 16:01:45 pts/4       0:00 /usr/local/bin/sudo /tmp/sudotest2
    root 12440 12439   0 16:01:45 pts/4       0:00 /bin/sh /tmp/sudotest2
    root 12461 24744   0 16:01:50 pts/8       0:00 grep sudo
The process /usr/local/bin/sudo /tmp/sudotest2 will appear as long as the script is executed and ends only when the script is done.

3. Sudo 1.8.0
The same as case 2.

I presume /usr/local/bin/sudo /tmp/sudotest2 appeared in case 1, but only for a short while and I didn't catch it. It's role is just to start the script and then it ends.

Because of this behavior I encounter functionality problems when I start my applications using Sudo.

Thanks.
Comment 6 Todd C. Miller 2011-03-18 11:01:23 MDT
That is the expected behavior for sudo >= 1.7.3.  For sudo 1.7.x, the sudo process waits until the command is finished so it can close the PAM session.  For sudo 1.8.x, the sudo process waits until the command is complete so it can pass the exit status to the policy and/or I/O plugins.

What are the functionality problems are you experiencing.
Comment 7 Todd C. Miller 2011-03-22 09:50:04 MDT
If you absolutely must have the old behavior, you can disable PAM session support in sudo 1.7.x by passing configure the --disable-pam-session option.  This will not make a difference in sudo 1.8.x due to the plugin API requiring the command's exit status so you will unable to upgrade past sudo 1.7.x if you rely on this.
Comment 8 Radu Mihaescu 2011-03-22 10:10:36 MDT
(In reply to comment #7)
> If you absolutely must have the old behavior, you can disable PAM
> session support in sudo 1.7.x by passing configure the
> --disable-pam-session option.  This will not make a difference in sudo
> 1.8.x due to the plugin API requiring the command's exit status so you
> will unable to upgrade past sudo 1.7.x if you rely on this.

Thanks a lot for your support. I will need anyway to upgrade Sudo to >1.7.x at a certain time. I am working on some workarounds on our software.