[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.20.1607041531310.30017@s1.palsenberg.com>
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.
