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

[Ram]

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.

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.

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

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

> 
> The easiest way to listen inside the kernel for connector's 
> notifications is creating appropriate socket in userspace
> and then obtain it through the following code which must be
> run in context of the process that created above socket:
> 
> 	struct file *file;
> 	struct inode *inode;
> 	int err = 0;
> 	
> 	file = fget(userspace_socket_number_in_the_current_process_context);
> 	if (!file) {
> 		return -ENODEV;
> 	}
> 	inode = file->f_dentry->d_inode;
> 	if (inode->i_sock) {
> 		sock = SOCKET_I(inode);
> 		err = 0;
> 	} else {
> 		fput(file);
> 		err = -ENODEV;
> 	}
> 
> sock is struct sock, which then can be used for read/write
> operations using 
> kernel_recvmsg(sock, &msg, &iov, 1, size, 0);
> kernel_sendmsg(sock, &msg, &iov, 1, size);
> 
> with the following initialisation:
> 
> sock->sk->sk_allocation |= GFP_NOIO;
> iov.iov_base = buf;
> iov.iov_len = size;
> msg.msg_name = NULL;
> msg.msg_namelen = 0;
> msg.msg_control = NULL;
> msg.msg_controllen = 0;
> msg.msg_namelen = 0;
> msg.msg_flags = msg_flags | MSG_NOSIGNAL;
> 

right. thanks for the code snippet. I should be coding something
around these lines.
> 
> Of course it can be done directly from kernelspace without
> touching process's structures, but this way is easier.

Thanks,
RP

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