On Tue, 2005-03-22 at 21:51, Evgeniy Polyakov wrote: > On Wed, 2005-03-23 at 08:01 +0300, Evgeniy Polyakov wrote: > > On Tue, 2005-03-22 at 15:51 -0800, Jay Lan wrote: > > > > > > I see this issue less a case of bad guys vs. good guys. I see it > > > as various components doing system related work, but there is > > > no mechanism of knowing who is on who is off by today's patch. A > > > service listening to the fork connector can request to turn off > > > cn_fork_enable on exit and inadquately affect other services/daemons > > > listening to the same connector. It is not acceptable in my opinion. > > > > It is super-user who only is allowed to turn it off and even listen for > > events, > > since only super-user is allowed to bind socket to multicast netlink > > group. > > Super-user should not be allowed to control it's system? > > BTW, super-user can unload fork connector module, and none listener > will even know about it, it just stops to receive notification.
I see your point. Since the application has to be super-user to turn it off, and since super-user applications are trusted not to mis-behave, the current mechanism is relatively safe. I guess its the amount of checks you put in place, to prevent inadvertent shooting-in-the-foot. There is nothing one can do if the fork_connector module is yanked out. However there is something one can do, to prevent any arbitrary application from shutting down the fork-event stream. I think I can live with the current mechanism, under the assumption that no fork-event listner has a legitate reason to shut down the fork-event-stream. RP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
