Bugzilla – Bug 482
Sudo 1.7.4 - 1.8.0 problem
Last modified: 2011-08-24 10:19:43 MDT
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 !
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?
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.
(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).
(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?
(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.
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.
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.
(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.