From: Rich Felker <email@example.com>
Subject: Re: [musl] [PATCH] accept4: don't fall back to accept if we got unknown flags
Date: Tue, 28 Feb 2023 15:51:55 -0500 [thread overview]
Message-ID: <20230228205155.GL4163@brightrain.aerifal.cx> (raw)
On Tue, Feb 28, 2023 at 11:15:06PM +0300, Alexey Izbyshev wrote:
> On 2023-02-28 20:25, Rich Felker wrote:
> >On Tue, Feb 28, 2023 at 12:21:01PM -0500, Rich Felker wrote:
> >>On Tue, Feb 28, 2023 at 02:42:39AM +0300, Alexey Izbyshev wrote:
> >>> On 2023-02-28 01:38, Rich Felker wrote:
> >>> >On Mon, Feb 27, 2023 at 10:46:54PM +0300, Alexey Izbyshev wrote:
> >>> >>accept4 emulation via accept ignores unknown flags, so it can
> >>> >>spuriously
> >>> >>succeed instead of failing (or succeed without doing the action
> >>> >>implied
> >>> >>by an unknown flag if it's added in a future kernel). Worse, unknown
> >>> >>flags trigger the fallback code even on modern kernels if the real
> >>> >>accept4 syscall returns EINVAL, because this is indistinguishable from
> >>> >>socketcall returning EINVAL due to lack of accept4 support. Fix
> >>> >>this by
> >>> >>always propagating the syscall attempt failure if unknown flags are
> >>> >>present.
> >>> >>
> >>> >>The behavior is still not ideal on old kernels lacking accept4
> >>> >>on arches
> >>> >>with socketcall, where failing with ENOSYS instead of EINVAL
> >>> >>returned by
> >>> >>socketcall would be preferable, but at least modern kernels are now
> >>> >>fine.
> >>> >
> >>> >Can you clarify what you mean about ENOSYS vs EINVAL here? I'm not
> >>> >following.
> >>> >
> >>> Sorry for confusion, I meant the following. On arches with
> >>> socketcall, if a program running on an old kernel that doesn't
> >>> support accept4 in any form calls accept4 with unknown flags, musl's
> >>> accept4 will fail with EINVAL after this patch. But the reason of
> >>> failure remains unclear to the programmer: is it because some flag
> >>> is not supported or because accept4 is not supported at all? So I
> >>> thought it'd be better to fail with ENOSYS in this case instead,
> >>> although I don't know a good way to do that: the EINVAL ambiguity
> >>> exists at socketcall level too, so testing whether the kernel's
> >>> socketcall supports __SC_accept4 or not would probably involve
> >>> calling it with known-good arguments on a separately created socket,
> >>> and I certainly don't propose to do that.
> >>> On the other hand, it could be argued that a function that can
> >>> emulate a certain baseline feature set of another function shouldn't
> >>> fail with ENOSYS at all because the real function would never do
> >>> that. The two cleanest options for possibly-not-supported functions
> >>> seem to be either always failing with ENOSYS if the kernel doesn't
> >>> support the syscall or failing with a reasonable error if the caller
> >>> requests something unsupported by the emulation. And I think accept4
> >>> satisfies the latter with this patch.
> >>> As an aside, note that dup3 and pipe2 currently also ignore unknown
> >>> flags on old kernels, and for pipe2 there is a valid flag (O_DIRECT)
> >>> that could be silently ignored because of that. But there is no
> >>> issue on newer kernels supporting the syscalls, unlike for accept4.
> >>The dup3 situation is even worse than you thought. The dup3 syscall is
> >>only attempted if O_CLOEXEC is set in flags. If not, the rest of flags
> >>are ignored and the dup2 syscall is made. I'll make a fix.
> Indeed, I missed that, thanks.
> >These should fix both..
> The patches look good to me.
> But looking at dup3 more closely, I've noticed another bug: fcntl is
> called even if SYS_dup2 fails. So on kernels where SYS_dup3 is
> unavailable, dup3(-1, fd, O_CLOEXEC) will wrongly try to set
> FD_CLOEXEC on fd.
Thanks for catching that. I'll fix it too.
prev parent reply other threads:[~2023-02-28 20:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-27 19:46 Alexey Izbyshev
2023-02-27 22:38 ` Rich Felker
2023-02-27 23:42 ` Alexey Izbyshev
2023-02-27 23:51 ` Alexey Izbyshev
2023-02-27 23:53 ` Rich Felker
2023-02-28 17:21 ` Rich Felker
2023-02-28 17:25 ` Rich Felker
2023-02-28 20:15 ` Alexey Izbyshev
2023-02-28 20:51 ` Rich Felker [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).