From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10164 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: abort() fails to terminate PID 1 process Date: Mon, 20 Jun 2016 12:04:43 +0200 Message-ID: <20160620100443.GV22574@port70.net> References: 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 1466417121 30885 80.91.229.3 (20 Jun 2016 10:05:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 10:05:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10176-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 20 12:05:15 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 1bEw4g-0002GB-6I for gllmg-musl@m.gmane.org; Mon, 20 Jun 2016 12:04:58 +0200 Original-Received: (qmail 19467 invoked by uid 550); 20 Jun 2016 10:04:55 -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 18422 invoked from network); 20 Jun 2016 10:04:55 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:10164 Archived-At: * Igmar Palsenberg [2016-06-20 11:02:15 +0200]: > > #include > > int main () > > { > > abort(); > > } > > > > with "unshare --fork --pid" so that it runs as PID 1 in it's own PID > > namespace. > > > > Would it be reasonable to add a fallback strategy in abort() for terminating > > processes when the signals don't have any effect? > > This is a bad idea. > > First, processes kan install handlers, which might > instruct the kernel to ignore the signal. SIGABORT can be ignored. I don't abort() should terminate the process even if SIGABRT is ignored. > expect my process to be SIGILL'ed next because of this (which, can also be > ignored). > Libc should NOT mess with these kind of things, that's up to the > application. the glibc fallbacks are change signal mask and set default handling for SIGABRT raise(SIGABRT); "abort instruction" (segfault, sigtrap or sigill depending on target) _exit(127); infinite loop http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=155d70b0647e848f1d40fc0e3b15a2914d7145c0;hb=HEAD on x86 glibc, pid 1 would terminate with SIGSEGV (unless there is a segfault handler). the musl logic is explained in http://git.musl-libc.org/cgit/musl/commit/?id=2557d0ba47286ed3e868f8ddc9dbed0942fe99dc neither of them is correct because it is not possible to exit with the right status in general. SIGKILL can only be ignored by pid 1 whose exit status is not supposed to be observable so musl may want to have a fallback after it since the pid namespace thing is nowadays widely abused on linux. > > Second the behaviour you're seeing is due to the kernel's special PID 1 > handling : It ignores signals send to pid 1 for which an explicit handler > has nog been installed. > > Remedy : Fix your application. Better : Fix your whole setup, if you need > these changes, it's broken by design. > > > > Igmar