From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from brightrain.aerifal.cx (brightrain.aerifal.cx [216.12.86.13]) by sourceware.org (Postfix) with ESMTPS id 5E3C43858C2D for ; Fri, 5 Aug 2022 19:17:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E3C43858C2D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=libc.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=libc.org Date: Fri, 5 Aug 2022 15:17:18 -0400 From: Rich Felker To: Florian Weimer Cc: Po Lu via Libc-alpha , Po Lu Subject: Re: Hook for `_exit' Message-ID: <20220805191717.GW7074@brightrain.aerifal.cx> References: <87les389c6.fsf.ref@yahoo.com> <87les389c6.fsf@yahoo.com> <871qtv2j7w.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <871qtv2j7w.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2022 19:17:22 -0000 On Fri, Aug 05, 2022 at 10:22:11AM +0200, Florian Weimer via Libc-alpha wrote: > * Po Lu via Libc-alpha: > > > I'd like to ask for a hook run before _exit kills the current thread. > > The reason for requesting such a hook is that badly behaved libraries > > such as GTK call _exit when the display connection is lost, without > > leaving programs a chance to perform cleanup, such as saving files that > > the user was working on. > > > > AFAIR, the GTK developers have already mentioned that they are unwilling > > to add such a hook on their end (especially to GTK 3, which is no longer > > receiving new features), and the chance of updated GTK versions getting > > to users is exceedingly slim. > > > > A real life example of this problem would be: > > > > https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-08/msg00433.html > > > > Where a user experienced a display disconnect, and as a result lost all > > of his work with no clear indication of what happened. > > I think even if we add the hook in glibc, GTK will find a way to > terminate the process immediately by other means. We already have exit, > yet GTK deliberately chose not to use it. So it doesn't look like > something that can be solved with an in-process hook. Exactly. This is just inviting an arms race. Next GTK does syscall(__NR_exit_group, 1) and then glibc has to make syscall() check for __NR_exit_group and call the application callback. Then GTK inlines asm, and glibc needs to install a seccomp handler to block it. Next... And that's not even to mention the flip side problem this invites: bad library code installing hooks for _exit that interfere with the application's usage of it and make it unsafe, by doing things from the callback that aren't safe in the context _exit is called from -- _exit is required to be async-signal safe and can be called from all sorts of nasty contexts, even vfork child(!!), where it's not safe for random callback code to run. > If you need to use a library with such an approach to error handling, > but you want to recover from errors, you need to use fork and confine > its use to a subprocess, and employ some IPC mechanism to maintain > relevant state in a more persistent process (or keep a redo log in the > file system). Exactly. If you're going to run badly-behaved library code, you either need to patch the bad behavior out of the library, or run the library in an isolated execution context where it can't do any harm. The latter is really the right approach here. Work out a protocol for communication between a UI child process and the actual core program and sandbox the former.