[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chet Ramey
Subject: Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'
Date: Wed, 9 Mar 2022 11:18:53 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.2

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

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]