Re: [patch 1/2] fork_connector: add a fork connector

[Ram]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/