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

[Evgeniy Polyakov]

On Tue, 2005-03-22 at 12:42 -0800, Ram wrote:
> On Tue, 2005-03-22 at 12:25, Evgeniy Polyakov wrote:
> > On Tue, 22 Mar 2005 11:18:07 -0800
> > Ram <linuxram@xxxxxxxxxx> wrote:
> > 
> > > > 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.
> > > > 
> > > > 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.
> > > 
> > > Yes. non-priviledged userspace processes should not know
> > > any deep kernel internals through connector events.
> > > 
> > > I think what I am driving at is, an application that is critically
> > > dependent on the fork-notification, suddenly stops receiving such
> > > notification because some other application has switched off the 
> > > service without its notice. 
> > > 
> > > the reason I am concerned is I am planning to feed this fork-events
> > > to my in-kernel module. Side note: I would really like support for
> > > in-kernel listners through connector infrastructure.
> > 
> > fork connector can be extended to send to the rest of the world
> > information that it was turned off or on.
> 
> This will support the paradigm: "Let me know if this is switched off,
> and I don't mind any arbitrary process switching it off".  No
> applications can seriously rely on this service, because there is this
> *arbritray-application-being-able-to-control* component to it.

It is fork connector who will inform all it's listeners that it is not
working any more.
And it is only super-user who can turn it off.

> A ideal paradigm would be: "Don't switch it off, without my consent".
> Essentially this will give applications enough confidence to rely on it
> seriously.

Does ip command wait until apache or bind exited when trying to turn 
network interface off? No. One can even unload network driver.
Because super-user must have ability to control the whole system.

> However an inbetween paradigm that would acceptable is:
> "Let me know if this is swtiched off provided only application that I
> can trust-on has the power to manage it".

I suppose fork connector [kernel module] is trusted enough application
that can inform external listeners about it's status.
But super-user still can turn it off by any program,
like one can turn network interface off using ip, ifconfig, your own 
application that can, btw, do it using netlink socket.

> To me 2nd or 3rd paradigm seems acceptable, but not the 1st.

Ok, fork module can implement following controlling mechanism:
on insert time super-user provides pid of the controlling 
program, later in fork callback it searches for the given pid, 
sends some signal to it, and if it receives 
magic message [with signal number for example] after it, then it is ok
to perform desired action.
I believe there are plenty of auth techniques that can be applied
here, but I strongly object against it.

What would happen with the system, if only one controlling daemon 
is allowed to turn networking off, or change hard drive work modes,
or super-user could not be allowed to remove user's file using usual
rm comman, but not specially authentificated daemon?
Or if it should ask all user's application, do they agree
to remove user's files?

> Thanks,
> RP
> 
> > 
> > > RP
> > 
> > 	Evgeniy Polyakov
> > 
> > Only failure makes us experts. -- Theo de Raadt
-- 
        Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski

Attachment: signature.asc
Description: This is a digitally signed message part