bug#22354: Hash-bang line length

bug#22354: Hash-bang line length

[Ludovic Courtès]

Hello,

The ‘READ_SAMPLE_BUF’ macro in execute_cmd.c reads at most 80 bytes from
the hash-bang line.  This is less than the already-small 128-byte limit
in the Linux kernel¹ and can quite easily be hit².

What about changing it to 128 bytes (as well as the ‘sample’ array) to
at least match Linux?

(It might even make sense to make it bigger so that Bash might succeed
when the kernel simply fails.)

Thanks,
Ludo’.

¹ http://lxr.free-electrons.com/source/include/uapi/linux/binfmts.h#L18
² See <http://bugs.gnu.org/22354>.

bug#22354: Hash-bang line length

[Greg Wooledge]

On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
> Hello,
> 
> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
> the hash-bang line.  This is less than the already-small 128-byte limit
> in the Linux kernel¹ and can quite easily be hit².

That's actually much bigger than one expects for shebang handling on
any traditional Unix system.

http://www.in-ulm.de/~mascheck/various/shebang/ is by far the most
authoritative source on the topic, and it shows limits of 16 to 32
bytes for the first implementations.  Later, it mentions that Linux's
implementation started at 1022, then was changed to 127.

bug#22354: Hash-bang line length

[Ludovic Courtès]

Greg Wooledge <wooledg@eeg.ccf.org> skribis:

> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
>> Hello,
>> 
>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
>> the hash-bang line.  This is less than the already-small 128-byte limit
>> in the Linux kernel¹ and can quite easily be hit².
>
> That's actually much bigger than one expects for shebang handling on
> any traditional Unix system.

Sure, but the fact that it’s smaller than that of the kernel Linux is
problematic: when a hash-bang line > 127 chars is encountered, ‘execve’
fails with ENOENT, so Bash’s fallback code is executed, fails as well,
but it prints a misleading error message with an even more truncated
hash-bang line.

Ludo’.

bug#22354: Hash-bang line length

[Greg Wooledge]

On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
> Sure, but the fact that it???s smaller than that of the kernel Linux is
> problematic: when a hash-bang line > 127 chars is encountered, ???execve???
> fails with ENOENT, so Bash???s fallback code is executed, fails as well,
> but it prints a misleading error message with an even more truncated
> hash-bang line.

Let's suppose bash is changed to read a shebang line of unlimited length.
In your scenario, the script with the 150 character shebang fails at the
kernel level with ENOENT, so bash's fallback code runs, and the script
is executed by a new instance of bash.

This just masks the problem.  Now, your script ONLY works when you
run it from a bash shell.  Not from any other shell, not via C's exec(),
not via find -exec, etc.

That said, it's not bash's place to try to guess how the host system's
kernel will handle the shebang.  I certainly wouldn't expect bash to
tell me "Hey, this is Linux, so your shebang won't work because it's
more than 127 bytes."

I'm not sure what error message or behavior you think bash should employ
in this scenario.  I don't see any clear "best" choice here.

bug#22354: Hash-bang line length

[Chet Ramey]

On 1/13/16 5:25 AM, Ludovic Courtès wrote:
> Hello,
> 
> The ‘READ_SAMPLE_BUF’ macro in execute_cmd.c reads at most 80 bytes from
> the hash-bang line.  This is less than the already-small 128-byte limit
> in the Linux kernel¹ and can quite easily be hit².

That limit is huge compared to other Unixes, btw.

> What about changing it to 128 bytes (as well as the ‘sample’ array) to
> at least match Linux?
> 
> (It might even make sense to make it bigger so that Bash might succeed
> when the kernel simply fails.)

If the kernel returns an errno other than ENOEXEC, bash isn't going to
`succeed'.  This is entirely a cosmetic issue concerning the error message
bash prints when execve fails.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

bug#22354: Hash-bang line length

[Chet Ramey]

On 1/13/16 8:52 AM, Ludovic Courtès wrote:
> Greg Wooledge <wooledg@eeg.ccf.org> skribis:
> 
>> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
>>> Hello,
>>>
>>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
>>> the hash-bang line.  This is less than the already-small 128-byte limit
>>> in the Linux kernel¹ and can quite easily be hit².
>>
>> That's actually much bigger than one expects for shebang handling on
>> any traditional Unix system.
> 
> Sure, but the fact that it’s smaller than that of the kernel Linux is
> problematic: when a hash-bang line > 127 chars is encountered, ‘execve’
> fails with ENOENT, so Bash’s fallback code is executed, fails as well,

No.  Since the execve fails with ENOENT, bash just prints an error
message.

> but it prints a misleading error message with an even more truncated
> hash-bang line.

Again, it's only a cosmetic issue.  I don't have a problem with increasing
the buffer size, but let's not pretend it's anything but that.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

bug#22354: Hash-bang line length

[Chet Ramey]

On 1/13/16 9:04 AM, Greg Wooledge wrote:
> On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
>> Sure, but the fact that it???s smaller than that of the kernel Linux is
>> problematic: when a hash-bang line > 127 chars is encountered, ???execve???
>> fails with ENOENT, so Bash???s fallback code is executed, fails as well,
>> but it prints a misleading error message with an even more truncated
>> hash-bang line.
> 
> Let's suppose bash is changed to read a shebang line of unlimited length.
> In your scenario, the script with the 150 character shebang fails at the
> kernel level with ENOENT, so bash's fallback code runs, and the script
> is executed by a new instance of bash.

No, it isn't.  The execve fails with ENOENT, so bash just prints an error
message containing the interpreter name, which Ludo is reporting is
truncated.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

bug#22354: Hash-bang line length

[Greg Wooledge]

On Wed, Jan 13, 2016 at 11:23:34AM -0500, Chet Ramey wrote:
> On 1/13/16 9:04 AM, Greg Wooledge wrote:
> > On Wed, Jan 13, 2016 at 02:52:08PM +0100, Ludovic Courtès wrote:
> >> Sure, but the fact that it???s smaller than that of the kernel Linux is
> >> problematic: when a hash-bang line > 127 chars is encountered, ???execve???
> >> fails with ENOENT, so Bash???s fallback code is executed, fails as well,
> >> but it prints a misleading error message with an even more truncated
> >> hash-bang line.
> > 
> > Let's suppose bash is changed to read a shebang line of unlimited length.
> > In your scenario, the script with the 150 character shebang fails at the
> > kernel level with ENOENT, so bash's fallback code runs, and the script
> > is executed by a new instance of bash.
> 
> No, it isn't.  The execve fails with ENOENT, so bash just prints an error
> message containing the interpreter name, which Ludo is reporting is
> truncated.

Ah.  You're right, and I should have double-checked Ludo's understanding
of the code before responding.  I assumed Ludo's assertion was correct,
but it's not.

The "fallback code" is only executed when execve() fails with ENOEXEC.

bug#22354: Hash-bang line length

[Ludovic Courtès]

Chet Ramey <chet.ramey@case.edu> skribis:

> On 1/13/16 8:52 AM, Ludovic Courtès wrote:
>> Greg Wooledge <wooledg@eeg.ccf.org> skribis:
>> 
>>> On Wed, Jan 13, 2016 at 11:25:03AM +0100, Ludovic Courtès wrote:
>>>> Hello,
>>>>
>>>> The ???READ_SAMPLE_BUF??? macro in execute_cmd.c reads at most 80 bytes from
>>>> the hash-bang line.  This is less than the already-small 128-byte limit
>>>> in the Linux kernel¹ and can quite easily be hit².
>>>
>>> That's actually much bigger than one expects for shebang handling on
>>> any traditional Unix system.
>> 
>> Sure, but the fact that it’s smaller than that of the kernel Linux is
>> problematic: when a hash-bang line > 127 chars is encountered, ‘execve’
>> fails with ENOENT, so Bash’s fallback code is executed, fails as well,
>
> No.  Since the execve fails with ENOENT, bash just prints an error
> message.

Right, sorry for the confusion.

>> but it prints a misleading error message with an even more truncated
>> hash-bang line.
>
> Again, it's only a cosmetic issue.  I don't have a problem with increasing
> the buffer size, but let's not pretend it's anything but that.

Exactly.  I was talking about the “bad interpreter” error message
specifically.

Ludo’.

bug#22354: Hash-bang line length

[Chet Ramey]

On 1/13/16 12:41 PM, Ludovic Courtès wrote:

>>> but it prints a misleading error message with an even more truncated
>>> hash-bang line.
>>
>> Again, it's only a cosmetic issue.  I don't have a problem with increasing
>> the buffer size, but let's not pretend it's anything but that.
> 
> Exactly.  I was talking about the “bad interpreter” error message
> specifically.

OK, we'll try it.  Can't hurt.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/