[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210403154742.GM25400@brightrain.aerifal.cx>
Date: Sat, 3 Apr 2021 11:47:43 -0400
From: Rich Felker <dalias@...c.org>
To: Joakim Sindholt <opensource@...sha.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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 <opensource@...sha.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
