tech-kern archive

[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 Oct 21,  9:16am, Matthew Mondor wrote:
} 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.

    Although, I don't know much about kqueue, I disagree with this.
Passing kqueue FDs via fork could be considered an oversight,
especially since they don't normally get inherited.  However, passing
them via SCM_RIGHTS is a very deliberate action.  We should assume that
any application doing this knows what it is doing.

}-- End of excerpt from Matthew Mondor


Home | Main Index | Thread Index | Old Index