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. What problem could occur that EVFILT_PROC with NOTE_EXIT (as opposed to EVFILT_PROC with maybe other fflags) could make that couldn't occur by trying to put a kevent on a file descriptor. Is "abusively" monitoring a process a security hole? If it is, shouldn't a task manager be run as root to see when a root process dies? It would be difficult enough to discover a pid when you aren't supposed to since they probably wouldn't be stored unless they are going to be used. waitpid(pid, &status, WNOHANG); in a loop could do the same thing as that, but would be uglier to implement. I suppose it may be difficult to turn back now after pledging so much in a certain way.
On Thu, Jan 5, 2017, 14:41 Ted Unangst <t...@tedunangst.com> 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 > to this, or is there a reason that EVFILT_PROC is? wait() is a less powerful syscall than kevent().
