mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] Restrictions on child context after multithreaded fork
Date: Sun, 16 Aug 2020 14:33:23 -0400	[thread overview]
Message-ID: <20200816183323.GB3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <87eeo6ikhi.fsf@mid.deneb.enyo.de>

On Sun, Aug 16, 2020 at 07:11:37PM +0200, Florian Weimer wrote:
> * Rich Felker:
> 
> > On Sun, Aug 16, 2020 at 11:10:37AM +0200, Florian Weimer wrote:
> >> * Rich Felker:
> >> 
> >> > On some inspection, glibc does not actually attempt to make the child
> >> > environment unrestricted. The only things it does around fork are:
> >> 
> >> I think pthread_once initializers that have partially executed are
> >> also executed from the start in the child if initialization is
> >> requested again.
> >
> > I don't follow how pthread_once is related. The vast majority of the
> > things I found glibc doing no specific handling for are actual mutable
> > state not just on-demand initialization.
> 
> If a fork happens during a pthread_once initialization, the subsystem
> related to that becomes unavailable after fork.  The pthread_once_t
> reinitialization logic intends to avoid that.  Like resetting locks
> after fork in the new process, it is rather questionable.

Yes but initialization is hardly the interesting case. All of the
subsystems I highlighted were not initialization but mutable state:

- adding (or removing, if you have dlclose remove them like glibc
  does) exit handlers.

- loading (or unloading) shared libraries

- adding textdomains to gettext or changing the active default one

- opening named semaphores (has a lock because POSIX requires opening
  the same one more than once to return the same sem_t pointer rather
  than a second mapping of it).

- using syslog (there's at least some state with regard to the log fd
  and log levels)

- using any time functions that depend on the timezone

The pthread_once-like initializations are another set of potential
deadlocks on top of that.

Most of the above happen fairly infrequently, especially compared to
malloc, so they're less likely to be bit, but they are deadlock
hazards that prevent the child environment from being unrestricted.
syslog and time are probably the most likely to be hit.

Rich

  reply	other threads:[~2020-08-16 18:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-14 21:41 Rich Felker
2020-08-14 22:02 ` Florian Weimer
2020-08-14 22:14   ` Rich Felker
2020-08-15  0:47 ` A. Wilcox
2020-08-15  2:40   ` Rich Felker
2020-08-15  2:07 ` Ariadne Conill
2020-08-15  3:02   ` Rich Felker
2020-08-15  6:51 ` Timo Teras
2020-08-15 11:51   ` Natanael Copa
2020-08-15 16:25     ` Rich Felker
2020-08-16  1:27       ` Rich Felker
2020-08-16 12:48         ` Natanael Copa
2020-08-16  3:57 ` Rich Felker
2020-08-16  9:10   ` Florian Weimer
2020-08-16 16:56     ` Rich Felker
2020-08-16 17:11       ` Florian Weimer
2020-08-16 18:33         ` Rich Felker [this message]
2020-08-16  7:05 ` Pirmin Walthert
2020-08-16 16:55   ` Rich Felker
2020-09-30 18:38 ` Rich Felker

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200816183323.GB3265@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/musl/

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).