Messages in this thread | | | From | Samuel Dionne-Riel <> | Date | Wed, 13 Feb 2019 20:27:43 -0500 | Subject | Re: Userspace regression in LTS and stable kernels |
| |
On 13/02/2019, Kees Cook <keescook@chromium.org> wrote: > On Wed, Feb 13, 2019 at 4:41 PM Samuel Dionne-Riel > <samuel@dionne-riel.com> wrote: >> Before, the interpreter was still used (assuming it wasn't cut by the >> length), and the interpreter was free to re-read the shebang if >> desired. > > So, to address the "wrong binary" problem, how about we ENOEXEC only > if no newline or spaces are found in the string? >
If I understand right, you're asking whether it should return NOEXEC if, of the first 128 bytes of the shebang, there are no spaces, but a too long shebang? I wouldn't know for sure. The behaviour would change. Instead failing due to trying to execute a shortened path, it would fall back to the shell interpreter interpreting the file, which, due to the inclusion of a specific shebang, might be a wrong assumption still. Here I believe it's still in the "undefined behaviour" territory, but one where it fails early for the userspace.
I don't have a strong opinion, but having a special case depending on whitespace or not (well, possibility of the interpreter being truncated or not) feels off. As an end-user, I would rather it truncates, and show the truncated interpreter it tried to use (behaviour before regression), rather than fail in a way where the libc will continue executing using another unexpected interpreter.
Thinking in the principle of least astonishment, I would be less surprised to see a truncated path on exec() than seeing exec() use an unexpected interpreter.
-- — Samuel Dionne-Riel
| |