bug-bash
[Top][All Lists]
Advanced

[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 14:14:14 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.2

On 3/9/22 12:25 PM, Andreas Schwab wrote:
> On Mär 09 2022, Chet Ramey wrote:
> 
>> 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 is a recurring problem with docker, and all comes down to the
> syscall filter returning a bogus errno.  It happens every time a new
> syscall is introduced.

Yes, that's why it required the exact conditions to reproduce.

Ultimately, this comes down to gaps in the release engineering.


-- 
``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]