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.