On Thu, 31 May 2012 10:38:38 -0400 (EDT) Mouse <mo...@rodents-montreal.org> wrote:
> > Recently we found out (PR kern/46463) that kqueue() file descriptors, > > which originaly were designed to be "local process only" objects, > > could be passed with SCM_RIGHTS messages to other processes. [...] > > > I propose to not allow sending kqueue file descriptors [...] > > > Or are there any legit uses for "foreign" kqueue()s? > > It seems to me, for what it may be worth, that this is asking the > wrong question. Rather, I would ask whether there are illegitimate > uses for `foreign' kqueue descriptors, and, if not, fix them to be > passable like any other descriptors. It's true that it's normally the parent's reponsibility to decide which FDs to close or set close-on-exec before fork(2)... Was there a design decision not to inherit kqueue descriptors for security or complexity reasons? Since signals, signal mask, signal stack and restart/interrupt flags are also inherited according to sigaction(2), probably that an EVFILT_SIGNAL filter would still be valid... But how about EVFILT_TIMER? timer_create(2) timers are not inherited, setitimer(2) doesn't specify, but it also uses the same ptimers pool timer_create(2) uses. EVFILT_TIMER apears to use its own system though. For EVFILT_PROC, it appears to be for the specified process, so I guess it might still work if inherited? And there also EVFILT_VNODE... who knows what other filters might be added in the future? What I can see is that the implications of inheriting this special descriptor are quite more complex than for normal FDs... Which makes me think that it very well could be a design decision not to inherit these, in which case I don't object to also prevent passing it via SCM_RIGHTS ancillary message. -- Matt