Messages in this thread | | | From | Samuel Dionne-Riel <> | Date | Wed, 13 Feb 2019 19:41:18 -0500 | Subject | Re: Userspace regression in LTS and stable kernels |
| |
Thanks for CC'ing relevant folks.
On 13/02/2019, Richard Weinberger <richard.weinberger@gmail.com> wrote: > [CC'in relevant folks] > > On Thu, Feb 14, 2019 at 12:19 AM Samuel Dionne-Riel > <samuel@dionne-riel.com> wrote: >> >> Here is an example shebang causing an issue: >> >> #! /nix/store/mbwav8kz8b3y471wjsybgzw84mrh4js9-perl-5.28.1/bin/perl >> -I/nix/store/x6yyav38jgr924nkna62q3pkp0dgmzlx-perl5.28.1-File-Slurp-9999.25/lib/perl5/site_perl >> -I/nix/store/ha8v67sl8dac92r9z07vzr4gv1y9nwqz-perl5.28.1-Net-DBus-1.1.0/lib/perl5/site_perl >> -I/nix/store/dcrkvnjmwh69ljsvpbdjjdnqgwx90a9d-perl5.28.1-XML-Parser-2.44/lib/perl5/site_perl >> -I/nix/store/rmji88k2zz7h4zg97385bygcydrf2q8h-perl5.28.1-XML-Twig-3.52/lib/perl5/site_perl > > This this ever work correctly? It is longer than BINPRM_BUF_SIZE. >
Yes, this is longer than BINPRM_BUF_SIZE. This worked when the interpreter knew to re-read the shebang, which among other interpreters, perl did.
https://perl5.git.perl.org/perl.git/blob/04db542212fdad3a62f13afe741c99028f4bf799:/toke.c#l5524
>> (The shebang was artificially wrapped spaces replaced by newlines) >> >> Another contributor tracked the regression it to commit >> 8099b047ecc431518b9bb6bdbba3549bbecdc343 in the 5.0-rc* tree. >> >> I bring no particular fix to the issue, but I believe it should at >> least be fast-tracked to a revert for the stable and LTS branches, and >> since 5.0 might drop soon, a solution worked on, or possibly a revert >> until one is figured out. > > Your shebang line exceeds BINPRM_BUF_SIZE. > Before the said commit the kernel silently truncated the shebang line > (and corrupted it), > now it tells the user that the line is too long. >
Yes, the shebang line exceeds BINPRM_BUF_SIZE.
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.
With the new behaviour, instead of executing the interpreter with a possibly truncated command line, the default script interpreter is used, meaning that the perl script is being interpreted by the wrong interpreter, giving copious amounts of irrelevant errors. This is not telling the user that the line is too long.
This provably breaks the userland as under 4.14.98 the perl interpreter is used when running the script, and under 4.14.99 bash is used when running the script.
For a given script with a shebang of #!(124*A)ZBBB:
The behaviour as of before the regression:
sh: ./foolish: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ: bad interpreter: No such file or directory
As expected, it cuts the shebang.
The behaviour following the change is the script ends up being executed by the shell interpreter, as if there was no shebang, and +x.
Quoted from `man 3 exec`
> If the header of a file isn't recognized (the attempted execve(2) failed with the error ENOEXEC), these functions will execute the shell (/bin/sh) with the path of the file as its first argument. (If this attempt fails, no further searching is done.)
The now returned ENOEXEC might be "more right", but changes the semantics of a truncated shebang.
Here I am not debating the validity of using a truncated shebang, but showing that the userspace behaviour changed in an unexpected and breaking behaviour.
Am I under a wrong assumption that the kernel shouldn't break userspace?
-- — Samuel Dionne-Riel
| |