[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Should kqueue descriptors work outsid of the creating process?
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
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.
Main Index |
Thread Index |