Re: [musl] graceful nscd fallback on kernels without AF_UNIX support

[Rich Felker <dalias@libc.org>]

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 <opensource@zhasha.com>
> > > 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