From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21483 invoked from network); 24 Jul 2021 05:56:41 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jul 2021 05:56:41 -0000 Received: (qmail 1052 invoked by uid 550); 24 Jul 2021 05:56:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1027 invoked from network); 24 Jul 2021 05:56:37 -0000 Date: Sat, 24 Jul 2021 01:56:25 -0400 From: Rich Felker To: Yuri Kanivetsky Cc: musl@lists.openwall.com Message-ID: <20210724055625.GN13220@brightrain.aerifal.cx> References: <20210724014021.GM13220@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210724014021.GM13220@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] faccessat() always return EPERM On Fri, Jul 23, 2021 at 09:40:22PM -0400, Rich Felker wrote: > On Sat, Jul 24, 2021 at 04:16:25AM +0300, Yuri Kanivetsky wrote: > > Hi, > > > > I'm not sure that it has something to do with musl. But experienced in > > a Alpine Linux docker container (ruby:2.6-alpine3.14) on Debian 9 or > > 10. I can't reproduce it with Alpine Linux 3.13 (container) or Debian > > 8 (host). > > > > For example, the following program outputs -1: > > > > #include > > #include > > #include > > > > int main() > > { > > int r; > > r = faccessat(AT_FDCWD, "/", R_OK, AT_EACCESS); > > printf("%i", r); > > return 0; > > } > > > > I believe whatever is passed as the second parameter, it would return -1. > > > > As a result at least irb and bundler doesn't work. Is this some sort > > of binary incompatibility with Linux kernel? > > No, it's almost surely Docker blocking the operation with the wrong > error code (EPERM): > > https://github.com/opencontainers/runc/issues/2151 > > I'm not sure what the status on getting fix deployed is. It might go > away if the host running Docker can upgrade. I forgot to mention: if you can disable seccomp in Docker, that's a workaround that doesn't require upgrading.