[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YGiD2yEDG1PT2daR@wirbelwind.zhasha.com>
Date: Sat, 3 Apr 2021 17:03:55 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: 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 <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().
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.
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.
