From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25428 invoked from network); 16 Aug 2020 18:33:38 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 16 Aug 2020 18:33:38 -0000 Received: (qmail 31818 invoked by uid 550); 16 Aug 2020 18:33:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31797 invoked from network); 16 Aug 2020 18:33:35 -0000 Date: Sun, 16 Aug 2020 14:33:23 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200816183323.GB3265@brightrain.aerifal.cx> References: <20200814214136.GP3265@brightrain.aerifal.cx> <20200816035759.GW3265@brightrain.aerifal.cx> <87h7t3j6r6.fsf@mid.deneb.enyo.de> <20200816165642.GZ3265@brightrain.aerifal.cx> <87eeo6ikhi.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87eeo6ikhi.fsf@mid.deneb.enyo.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Restrictions on child context after multithreaded fork 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