>You could possibly make a separate "event" or "wait" pledge to register new
>events or NOTE_EXIT calls, but I suspect that that would complicate things,
>making the large presumption that that could be desired.
Why would we do that?
We've not seen any source code which requires what you
You could possibly make a separate "event" or "wait" pledge to register new
events or NOTE_EXIT calls, but I suspect that that would complicate things,
making the large presumption that that could be desired.
On Thu, Jan 5, 2017, 15:42 Theo de Raadt wrote:
> > I imagine
> I should also clarify a bit. wait() only works for processes you've created
> with fork(), which requires "proc". There's good reason to allow you to watch
> for a child's exit much later, but without the ability to fork again.
that's right.
during development of pledge, we found many
> I imagine that the mitigation that is sought by pledge is to minimize
> aberrent code reuse in whatever way a hacker can make code run again in a
> way that it isn't supposed to. And maybe the programmer can choose what can
> be problematic and what isn't if it runs again with their choice of
Registering a EVFILT_PROC, NOTE_EXIT kevent requires proc
On Thu, Jan 5, 2017, 15:25 Ted Unangst wrote:
> Theo de Raadt wrote:
> > > Luke Small wrote:
> > > > What if I want to prevent a process from forking while I want to
> create new
> > > > EVFILT_PROC events? Say, to
Theo de Raadt wrote:
> > Luke Small wrote:
> > > What if I want to prevent a process from forking while I want to create
> > > new
> > > EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
> > > and load it into a kqueue. Is there a reason why waitpid() isn't beholden
> > >
I imagine that the mitigation that is sought by pledge is to minimize
aberrent code reuse in whatever way a hacker can make code run again in a
way that it isn't supposed to. And maybe the programmer can choose what can
be problematic and what isn't if it runs again with their choice of the
calls.
> Luke Small wrote:
> > What if I want to prevent a process from forking while I want to create new
> > EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
> > and load it into a kqueue. Is there a reason why waitpid() isn't beholden
> > to this, or is there a reason that
Luke Small wrote:
> What if I want to prevent a process from forking while I want to create new
> EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
> and load it into a kqueue. Is there a reason why waitpid() isn't beholden
> to this, or is there a reason that EVFILT_PROC
> What if I want to prevent a process from forking while I want to create new
> EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
> and load it into a kqueue. Is there a reason why waitpid() isn't beholden
> to this, or is there a reason that EVFILT_PROC is?
Your usage case
What if I want to prevent a process from forking while I want to create new
EVFILT_PROC events? Say, to accept the pid of a sibling fork from a pipe
and load it into a kqueue. Is there a reason why waitpid() isn't beholden
to this, or is there a reason that EVFILT_PROC is?
11 matches
Mail list logo