[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 15 Aug 2020 12:25:47 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Restrictions on child context after multithreaded fork
On Sat, Aug 15, 2020 at 01:51:00PM +0200, Natanael Copa wrote:
>
>
> > 15. aug. 2020 kl. 08:51 skrev Timo Teras <timo.teras@....fi>:
> >
> > On Fri, 14 Aug 2020 17:41:38 -0400
> > Rich Felker <dalias@...c.org> wrote:
> >
> >> musl 1.2.1 has exposed bugs in several applications and libraries
> >> caused by async-signal-unsafe code between (multithreaded) fork and
> >> subsequent exec. So far, dbus library code, pulseaudio library code,
> >> and libvirt have been found to be affected. A couple of the bug
> >> reports (with incomplete information) are:
> >>
> >> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11602
> >> https://gitlab.alpinelinux.org/alpine/aports/-/issues/11815
> >
> > Add to that list glib and libvte.
> >
> > XFCE4 became quite unusable due to glib. Fortunately, it was fixed
> > quite fast, and is merged for Alpine already:
> > https://gitlab.gnome.org/GNOME/glib/-/issues/2140
> >
> > Unfortunately, libvte duplicates the some of the code and the issue:
> > there's https://gitlab.gnome.org/GNOME/vte/-/issues/263
> > That got fixed relatively fast too in git master, but is not backported
> > to any stables branch. So that's not merged yet in Alpine. And is
> > causing still random lock ups in e.g. xfce4-terminal.
> >
>
> xfce4-terminal was more or less completely useless so I had to add a workaround for it in two patches:
>
> First uncover a useless setenv. Even the comment in the code says that it has no effect:
> https://git.alpinelinux.org/aports/commit/community/vte3?id=ad687b01b2a5fa9d53fcd9d0ee3743882f3542b4
>
> In the second patch I use some of the hunks in the upstream and replace malloc with alloca:
> https://git.alpinelinux.org/aports/commit/community/vte3?id=161434fcb87807dae40dffdd332db1624b747bc7
>
> After that xfce4-terminal becomes useable again.
I'm not sure whether the alloca is safe. The parent could just do this
allocation *before fork* rather than waiting til the last minute to do
it. The data does not change between fork and exec. Note that the glib
fix cited above did this right.
The hardcoded fallback for fd limit seems like a bad idea, and I don't
think I understand your fallback sequence. It looks like RLIM_INFINITY
gets reinterpreted as 4096. I'm not sure how it should be interpreted;
in principle, probably as INT_MAX+1U. This is again exposing how the
whole "close-all" idiom is horribly wrong and these libraries should
just be documenting that you must use O_CLOEXEC correctly if you don't
want them to leak file descriptors.
For what it's worth, I don't really see any reason prlimit should be
treated as AS-safe but getrlimit and sysconf shouldn't. I'm fairly
well in favor of having at least sysconf be one of the functions musl
makes AS-safe as an extension, though perhaps we should discuss that
more. (Actually I'd like to make a project of documenting everything
we make AS-safe, including things like strerror, dprintf/snprintf,
etc.)
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.
