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

[Evgeniy Polyakov <johnpol@2ka.mipt.ru>]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

On Tue, 2005-03-22 at 15:51 -0800, Jay Lan wrote:

> >>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.

And connector's listeners will continue to listen it's events.
But there will not be any event.
Like application will continue to be bound to the IP and listen
for incomming connection, but there will not be any connection.

> > 
> > 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.

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?

> 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?

With CBUS it costs nothing to always send notifications,
but I still do not see a point of disallowing super-user to stop
fork notifications using arbitrary application.

> Thanks,
> - jay

-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]