Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'

[Chet Ramey]

On 2/22/22 10:10 AM, Benoit Lacelle wrote:

> Bash Version: 5.1
> Patch Level: 16
> Release Status: relase
> Bash version: 5.1.16(1)-release (x86_64-alpine-linux-musl)
> 
> Description:
> Issue discussed at https://github.com/disney/meteor-base/pull/102
> Supposedly related with Bash5.1, 'hash npm' now fails in very recent bash,
> but not in local macos bash, nor older linux docker images bashes
> 
> 
> Repeat-By:
> Supposedly related with upgrade of Docker node image: 'FROM
> node:14.18.2-alpine', or 'RUN apk --no-cache add bash'

Closing the loop here.

The issue is related to a combination of musl libc, Alpine Linux 3.14, and
the docker version CircleCI was using.

Basically, musl libc enabled the faccessat2(2) system call and started
using it in faccessat(2). access(2) ends up calling faccessat, which now
uses faccessat2 if it's available. Alpine Linux 3.14 incorrectly returned
EPERM for unknown system calls instead of ENOSYS when running under the
faulty Docker version, which didn't know about faccessat2. EPERM has the
obvious meaning when access(2) returns it; the caller can't just assume
that EPERM means "system call blocked by security policy." And so bash
assumed that access returning EPERM meant that the binary wasn't
executable.

This has all been fixed in the current versions of Alpine Linux and the
CircleCI Docker version.

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