From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10291 Path: news.gmane.org!not-for-mail From: Igmar Palsenberg Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() fails to terminate PID 1 process Date: Mon, 4 Jul 2016 15:37:35 +0200 (CEST) Message-ID: References: <20160620100443.GV22574@port70.net> <20160620194110.GM10893@brightrain.aerifal.cx> <20160703135846.GF15995@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1467640230 12074 80.91.229.3 (4 Jul 2016 13:50:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 13:50:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10303-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 04 15:50:29 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bK43j-0008Kq-Cy for gllmg-musl@m.gmane.org; Mon, 04 Jul 2016 15:37:12 +0200 Original-Received: (qmail 25695 invoked by uid 550); 4 Jul 2016 13:37:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 25677 invoked from network); 4 Jul 2016 13:37:08 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 s1.palsenberg.com u64DbZOP011677 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=palsenberg.com; s=s1; t=1467639456; bh=2vJG6tj5dWw3h9KwBci/R2qJPDGGylAXwCwkt7EDxig=; h=Date:From:To:Subject:In-Reply-To:References:From; b=NcL9R9Qx/Fi0wey4DaBwfELdV3kCrLp4+5a4jgEG5uiKR6LAaEr+uI5BD0QwY//iW YWN11FcsIBYGJ72ppq5YRwkmVGOz6uGGOpNFzCx1nsv+STshVVeO+L+YY++3li1UB9 44kkChnyZ460AELnwyD9yvc2vHzMw30upbKBn8h8= In-Reply-To: <20160703135846.GF15995@brightrain.aerifal.cx> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.5.16 (s1.palsenberg.com [127.0.0.1]); Mon, 04 Jul 2016 15:37:36 +0200 (CEST) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on s1.palsenberg.com Xref: news.gmane.org gmane.linux.lib.musl.general:10291 Archived-At: > Whether you realize it or not, what you're saying is equivalent to > saying that it's UB for a process that runs as pid 1 to call abort(). > There is no basis for such a claim. > > A vague "pid 1 is special" rule (which the standard does not support > except in a few very specific places where an implementation-defined > set of processes are permitted to be treated in specific special ways) > does not imply "calling a function whose behavior is well-defined can > legitimately lead to runaway code execution if the pid is 1". But doesn't "bevavior is well-defined" also imply that that function behaves as it should ? If it doesn't, doesn't the "well-defined" no longer apply ? I call it UB in this case. The standard also says a process can't ignore a SIGKILL, but on pid 1, it has no effect. I pretty much call that UB myself. > > Can this even be reproduced under normal circumstances (aka : not pid 1) ? > > If thes, then I agree : It's a bug. If no : Then not. If people have a > > broken container init system, then it breaks and they keep the pieces. > > Yes. It it can be reproducted when not pid 1, then agree, it's a bug. > > > > Well, normally abort() does some signal magic, and then raises again. > > > > Which is what POSIX mandates I think. > > > > > > To make this work reliably I think we need to make abort() take a lock > > > the precludes further calls to sigaction prior to re-raising SIGABRT > > > and resetting the disposition. But there are all sorts of > > > complications to deal with. For example if another thread performs > > > posix_spawn for fork and exec concurrent with abort() munging the > > > disposition of SIGABRT, the child process could start with the wrong > > > disposition for SIGABRT, which would be non-conforming. Finding ways > > > to fix all places where the wrong behavior may be observable is a > > > nontrivial problem. > > > > Does the whole guaranteed termination also includes threaded programs ? > > Of course. The fact that you're asking such basic questions tells me > that you're bikeshedding this based on negative opinions of certain > container usage cases and not offering constructive input based on > what the specification actually requires. I've seen this different in practice, that why I'm asking. I never debugged that one issue, it just "disappared" at a certain point, which I could never reproduce afterwards. I'm not bikeshedding container usage, I'm just seeing broken implementation in the wild (which do get rapidly fixed usually). Igmar