Date: Mon, 4 Jul 2016 15:37:35 +0200 (CEST) From: Igmar Palsenberg <igmar@...senberg.com> To: musl@...ts.openwall.com Subject: Re: abort() fails to terminate PID 1 process > 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.