From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 202F421672 for ; Fri, 17 Jan 2025 07:37:23 +0100 (CET) Received: (qmail 7572 invoked by uid 550); 17 Jan 2025 06:37:20 -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 x-ms-reactions: disallow Received: (qmail 7543 invoked from network); 17 Jan 2025 06:37:19 -0000 Date: Fri, 17 Jan 2025 01:37:09 -0500 From: Rich Felker To: Askar Safin Cc: musl Message-ID: <20250117063709.GJ10433@brightrain.aerifal.cx> References: <19471652a7a.50e9fe137311.5385327542827515244@zohomail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19471652a7a.50e9fe137311.5385327542827515244@zohomail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [bug] Ctrl-Z when process is doing posix_spawn makes the process hard to kill On Fri, Jan 17, 2025 at 03:14:03AM +0400, Askar Safin wrote: > I found a bug both in glibc and musl. > > If a process does posix_spawn+waitpid, then attempting to pause it using Ctrl-Z > sometimes doesn't work and, worse, makes the process unkillable by usual Ctrl-Z or Ctrl-C. > > The bug is described in full in this glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=32565 . > > It is reproducible with musl on the same system I used to reproduce it with glibc (see the link). > > I compiled the code using "x86_64-linux-musl-gcc" wrapper provided by Debian. > > Please, CC me when replying. OK, I think this should be fixable by, if SIGTSTP is to be SIG_DFL in the spawned child, setting it to a no-op handler instead of SIG_DFL. It might actually make sense to just do this for all signals. Note that SIGSTOP, which is not blockable interceptible or ignorable, can't be handled this way, but the pid has not yet leaked to anything at this point, so the only way SIGSTOP can be generated is by a badly behaved program signaling random pids, which is not a case that needs to be handled gracefully. In theory SIGTTIN and SIGTTOU might be hazards too, but I don't think it's possible for a process to generate them without attempting to perform io, which the pre-exec child doesn't do. Still handling them might be a good safety measure in case I'm wrong. I'll prepare one or more versions of a proposed patch. Rich