Bug 1373199 - sudo fails to report error correctly when exec fails
Summary: sudo fails to report error correctly when exec fails
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sudo
Version: 26
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Daniel Kopeček
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-05 13:14 UTC by Jakub Jelen
Modified: 2017-04-20 11:07 UTC (History)
4 users (show)

Fixed In Version: sudo-1.8.20-0.1.b1.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 828782
Environment:
Last Closed: 2017-04-20 08:40:46 UTC
Type: ---


Attachments (Terms of Use)

Description Jakub Jelen 2016-09-05 13:14:15 UTC
+++ This bug was initially created as a clone of Bug #828782 (slightly updated) +++

sudo fails to report the error correctly when the execv(3) library call fails. 

Version-Release number of selected component (if applicable): sudo-1.8.17p1-1.fc24.x86_64
sudo-1.8.18b2-1.fc26.x86_64

How reproducible: Always

Steps to Reproduce:

Perform the following steps:
cat <<EOF >script
#!/bin/some_nonexistent_shell
wibble wobble
EOF

chmod +x foo

# An attempt to exec foo will give an error due to a missing interpreter
# ./script; echo $?
-bash: ./script: /bin/some_nonexistent_shell: bad interpreter: No such file or directory
126

# An attempt by sudo to exec foo will give wrong exit code
# sudo ./script; echo $?
sudo: unable to execute ./script: No such file or directory
0

Actual results:
exit code 0

Expected results:
exit code 126 or similar


Additional info:
If I understand the debug messages, I see two (debug) return codes in the end of exectution, but only the second is obviously real return/exit:

Sep  5 14:15:52 sudo[17953] <- main @ ./sudo.c:330 := 129
Sep  5 14:15:52 sudo[17953] <- main @ ./sudo.c:334 := 0

If I see right, the intention was something like this:

diff --git a/src/sudo.c b/src/sudo.c
index 58085e9..c7e771e 100644
--- a/src/sudo.c
+++ b/src/sudo.c
@@ -329,6 +329,7 @@ main(int argc, char *argv[], char *envp[])
 	sudo_debug_exit_int(__func__, __FILE__, __LINE__, sudo_debug_subsys,
 	    WTERMSIG(status) | 128);                
 	kill(getpid(), WTERMSIG(status));
+	exit(WTERMSIG(status) | 128);
     }
     sudo_debug_exit_int(__func__, __FILE__, __LINE__, sudo_debug_subsys,
 	WEXITSTATUS(status));

Testing this specific use case gives me the expected results. Though not sure if it behaves correctly for all the other cases.

Comment 1 Fedora End Of Life 2017-02-28 10:12:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 Daniel Kopeček 2017-04-20 08:39:11 UTC
Seems to work with the current version

$ sudo ./script; echo $?
sudo: unable to execute ./script: No such file or directory
1

Comment 3 Jakub Jelen 2017-04-20 10:44:25 UTC
Exit code 1 does not seem to equal to 126 as we can see from the script running without sudo.

$ ./script; echo $?
bash: ./script: /bin/some_nonexistent_shell: bad interpreter: No such file or directory
126

$ sudo ./script; echo $?
sesh: unable to execute ./script: No such file or directory
1

And at Fedora 25 I am still getting `sesh` instead of `sudo`. That is also intentional?

sudo-1.8.19p2-1.fc25.x86_64

Comment 4 Daniel Kopeček 2017-04-20 11:07:35 UTC
(In reply to Jakub Jelen from comment #3)
> Exit code 1 does not seem to equal to 126 as we can see from the script
> running without sudo.

This is documented behaviour. Please read the "EXIT VALUE" section in the sudo man page.


Note You need to log in before you can comment on or make changes to this bug.