On Tue, 2005-03-22 at 12:25, Evgeniy Polyakov wrote:
> On Tue, 22 Mar 2005 11:18:07 -0800
> Ram <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
