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 8933 invoked from network); 3 Apr 2021 15:47:58 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Apr 2021 15:47:58 -0000 Received: (qmail 11468 invoked by uid 550); 3 Apr 2021 15:47:55 -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 11450 invoked from network); 3 Apr 2021 15:47:55 -0000 Date: Sat, 3 Apr 2021 11:47:43 -0400 From: Rich Felker To: Joakim Sindholt Cc: musl@lists.openwall.com Message-ID: <20210403154742.GM25400@brightrain.aerifal.cx> References: <20210403144256.GL25400@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] graceful nscd fallback on kernels without AF_UNIX support On Sat, Apr 03, 2021 at 05:03:55PM +0200, Joakim Sindholt wrote: > 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. Ah, I'd forgotten we discussed it before, but yes that makes sense. > > > >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(). Yes, I think EACCES is just for things like SOCK_RAW and IPPROTO_ICMP where they're restricted because they fundamentally allow bypassing the socket layer's model of address/service-port ownership. > 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. Yeah. Let's just do EAFNOSUPPORT then. Rich