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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 4159 invoked from network); 3 Apr 2021 15:04:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Apr 2021 15:04:11 -0000 Received: (qmail 30018 invoked by uid 550); 3 Apr 2021 15:04:08 -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 29996 invoked from network); 3 Apr 2021 15:04:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zhasha.com; s=wirbelwind; t=1617462236; bh=wEkKB6sGzjFGNDkXqo8RmU67sUevgUkpoDa0dRy+rDs=; h=Date:From:To:Subject:References:In-Reply-To; b=iommzBnZqIlbzUM/48DWc+5mSRtmRpgBWIxsXonN3jwPBxVFUDk2+kVJl1qzZSYjB isr+4Zfkeq5JGK/pbm+AmFFxaAd2aGyawFOVrnaUv6Yrh/vK46k72deXWVkvoNf8G0 Upu4FCAzgqqfmwAugtiO0Y7GIaIGqHecso/2cPBw= Date: Sat, 3 Apr 2021 17:03:55 +0200 From: Joakim Sindholt To: musl@lists.openwall.com Message-ID: References: <20210403144256.GL25400@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210403144256.GL25400@brightrain.aerifal.cx> Subject: Re: [musl] graceful nscd fallback on kernels without AF_UNIX support On Sat, Apr 03, 2021 at 10:42:57AM -0400, Rich Felker wrote: > On Sat, Apr 03, 2021 at 12:58:42PM +0200, Joakim Sindholt wrote: > > I was reminded of this coincidentally on IRC and apparently it was never > > applied, presumably because I never actually sent a proper patch. > > > > 5 years ago someone came in asking about musl on a system without > > AF_UNIX support and this patch is what we came up with. It does require > > access to /dev/null which might itself be a problem now that musl is > > shedding filesystem requirements. > > It's not really a problem, but it's also not necessary. fmemopen of an > empty buffer would also work, but might be undesirable for pulling in > more unnecessary code. So this is probably best as you wrote it: >From the old chat logs it seems we both agreed that opening /dev/null was preferable for the same reason. > > >From 9984ac4ad320844a91bbcdbc9f5fa07d3154621e Mon Sep 17 00:00:00 2001 > > From: Joakim Sindholt > > Date: Sat, 3 Apr 2021 12:50:18 +0200 > > Subject: [PATCH] nscd: fall back gracefully on kernels without AF_UNIX support > > > > --- > > src/passwd/nscd_query.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/src/passwd/nscd_query.c b/src/passwd/nscd_query.c > > index d38e371b..8641e4f0 100644 > > --- a/src/passwd/nscd_query.c > > +++ b/src/passwd/nscd_query.c > > @@ -40,7 +40,13 @@ retry: > > buf[0] = NSCDVERSION; > > > > fd = socket(PF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0); > > - if (fd < 0) return NULL; > > + if (fd < 0) { > > + if (errno == EACCES || errno == EAFNOSUPPORT || errno == EPROTONOSUPPORT) { > > + errno = errno_save; > > + return fopen("/dev/null", "re"); > > + } > > + return 0; > > + } > > What is the EACCESS case for here? EPROTONOSUPPORT is probably not > needed either (is it possible to have AF_UNIX supported but stream > mode support disabled?). Not a big deal but I'd rather not violate > YAGNI adding cases that don't have a legitimate reason to be possible. It's been so long that I can't remember. Best guess is that EACCES allows it to fall back in a hypothetical container where it's not allowed to call socket() but of course that should yield ENOSYS, a case we might want to handle instead, and will probably yield EPERM in current (last?) gen containers. I probably got it from Linux Programmer's Manual which says: EACCES Permission to create a socket of the specified type and/or protocol is denied. For what it's worth there's no mention of EACCES in net/unix and all other non-protocol-specific EACCES seem to be unrelated to socket(). As for EPROTONOSUPPORT: I can't find any config option in linux that disables stream/dgram/etc. Just CONFIG_UNIX that disables unix sockets entirely.