Messages in this thread | | | Date | Tue, 22 Mar 2005 15:51:39 -0800 | From | Jay Lan <> | Subject | Re: [patch 1/2] fork_connector: add a fork connector |
| |
Evgeniy Polyakov wrote: > On Tue, 22 Mar 2005 10:26:19 -0800 > Ram <linuxram@us.ibm.com> wrote: > > >>On Mon, 2005-03-21 at 23:07, Guillaume Thouvenin wrote: >> >>>On Mon, 2005-03-21 at 12:52 -0800, Ram wrote: >>> >>>> If a bunch of applications are listening for fork events, >>>> your patch allows any application to turn off the >>>> fork event notification? Is this the right behavior? >>> >>>Yes it is. The main management is done by application so, if several >>>applications are listening for fork events you need to choose which one >>>will turn off the fork connector. >>> >>>I want to keep this turn on/off mechanism simple but if it's needed I >>>can manage the variable "cn_fork_enable" as a counter. Thus the callback >>>could be something like: >>> >>>static void cn_fork_callback(void *data) >>>{ >>> int start; >>> struct cn_msg *msg = (struct cn_msg *)data; >>> >>> if (cn_already_initialized && (msg->len == sizeof(cn_fork_enable))) { >>> memcpy(&start, msg->data, sizeof(cn_fork_enable)); >>> if (start) >>> cn_fork_enable++; >>> else >>> cn_fork_enable > 0 ? cn_fork_enable-- : 0; >>> } >>>} >> >>I think a better way is: >> >> Providing a different connector channel called the administrator >> channel which can be used only by a super-user, and gives you >> the ability to switch on or off any connector channel including the >> fork-connector channel. > > > Only super-user can bind netlink socket to multicast group. > > >> For lack of better term I am using the word 'channel' to mean >> something that carries events of particular type through the >> connector-infrastructure. > > > I still do not see why it is needed. > Super-user can run ip command and turn network interface off > not waiting while apache or named exits or unbind.
You can turn off a network interface and turn it back on without closing a network application and it will continue to work.
> > In theory I can create some kind of userspace registration mechanism, > when userspace application reports it's pid to the connector, > and then it sends data to the specified pids, but does not > allow controlling from userspace. > But I really do not think it is a good idea to permit > non-priviledged userspace processes to know about deep > kernel internals through connector's messages.
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.
The idea of implementing fork connector enabling/disabling was so that the kernel does not waste time writing to the sockets if no application listening. If implementing such a feature costs more than it saves, maybe the fork connector should simply always send?
Thanks, - jay
> > >>RP >> >> >> >>> >>>What do you think about this implementation? >>> >>>Guillaume >>> > > > > Evgeniy Polyakov > > Only failure makes us experts. -- Theo de Raadt
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |