Re: Should kqueue descriptors work outsid of the creating process?

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Thu, 31 May 2012 10:38:38 -0400 (EDT)
Mouse <mouse%Rodents-Montreal.ORG@localhost> 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