| Message ID | 4ED7BC6E.3040600@parallels.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Pavel Emelyanov <xemul@parallels.com> Date: Thu, 01 Dec 2011 21:42:06 +0400 > Currently it's not possible to find out what processes are connected > to each other via a unix socket. In the proposed proc file a socket > inode number and its peer inode number are shown. With these two at > hands it's possible to determine the unix connections endpoints. > > Signed-off-by: Pavel Emelyanov <xemul@parallels.com> I'm basically against new networking procfs based information retrieval mechanisms. Please extend the netlink socket dumping so that it works with AF_UNIX sockets and subsequently added the necessary netlink attribute to provide the peer value. I plan to stand pretty firm on this, so you may want to save your effort and use said effort to implement this properly. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/04/2011 10:25 PM, David Miller wrote: > From: Pavel Emelyanov <xemul@parallels.com> > Date: Thu, 01 Dec 2011 21:42:06 +0400 > >> Currently it's not possible to find out what processes are connected >> to each other via a unix socket. In the proposed proc file a socket >> inode number and its peer inode number are shown. With these two at >> hands it's possible to determine the unix connections endpoints. >> >> Signed-off-by: Pavel Emelyanov <xemul@parallels.com> > > I'm basically against new networking procfs based information > retrieval mechanisms. So am I, just wanted to bring this topic up again. > Please extend the netlink socket dumping so that it works with > AF_UNIX sockets and subsequently added the necessary netlink > attribute to provide the peer value. OK, will do it this way. AFAIU you're talking about the NETLINK_INET_DIAG, right? > I plan to stand pretty firm on this, so you may want to save your > effort and use said effort to implement this properly. > > Thanks. > . > Thanks, Pavel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Pavel Emelyanov <xemul@parallels.com> Date: Mon, 05 Dec 2011 14:25:11 +0400 > On 12/04/2011 10:25 PM, David Miller wrote: >> Please extend the netlink socket dumping so that it works with >> AF_UNIX sockets and subsequently added the necessary netlink >> attribute to provide the peer value. > > OK, will do it this way. AFAIU you're talking about the NETLINK_INET_DIAG, right? Yes. If that framework, for some reason, doesn't fit AF_UNIX sockets well or needs to be genericized, please feel free to do whatever you think is necessary to address that. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c index 4b83a9c..4ce425a 100644 --- a/net/unix/af_unix.c +++ b/net/unix/af_unix.c @@ -2305,6 +2305,33 @@ static int unix_seq_show(struct seq_file *seq, void *v) return 0; } +static int unix_peers_seq_show(struct seq_file *seq, void *v) +{ + struct sock *s = v, *peer; + unsigned long ino, peer_ino = 0; + + if (v == SEQ_START_TOKEN) + return 0; + + unix_state_lock(s); + ino = sock_i_ino(s); + peer = unix_peer(s); + if (peer) + sock_hold(peer); + unix_state_unlock(s); + + if (peer) { + unix_state_lock(peer); + peer_ino = sock_i_ino(peer); + unix_state_unlock(peer); + + sock_put(peer); + } + + seq_printf(seq, "%5lu %5lu\n", ino, peer_ino); + return 0; +} + static const struct seq_operations unix_seq_ops = { .start = unix_seq_start, .next = unix_seq_next, @@ -2326,18 +2353,46 @@ static const struct file_operations unix_seq_fops = { .release = seq_release_net, }; +static const struct seq_operations unix_peers_seq_ops = { + .start = unix_seq_start, + .next = unix_seq_next, + .stop = unix_seq_stop, + .show = unix_peers_seq_show, +}; + +static int unix_peers_seq_open(struct inode *inode, struct file *file) +{ + return seq_open_net(inode, file, &unix_peers_seq_ops, + sizeof(struct unix_iter_state)); +} + +static const struct file_operations unix_peers_seq_fops = { + .owner = THIS_MODULE, + .open = unix_peers_seq_open, + .read = seq_read, + .llseek = seq_lseek, + .release = seq_release_net, +}; + static int unix_proc_create(struct net *net) { if (!proc_net_fops_create(net, "unix", 0, &unix_seq_fops)) goto out; + if (!proc_net_fops_create(net, "unix_peers", 0, &unix_peers_seq_fops)) + goto out_peers; + return 0; + +out_peers: + proc_net_remove(net, "unix"); out: return -ENOMEM; } static void unix_proc_destroy(struct net *net) { + proc_net_remove(net, "unix_peers"); proc_net_remove(net, "unix"); } #else
Currently it's not possible to find out what processes are connected to each other via a unix socket. In the proposed proc file a socket inode number and its peer inode number are shown. With these two at hands it's possible to determine the unix connections endpoints. Signed-off-by: Pavel Emelyanov <xemul@parallels.com> --- net/unix/af_unix.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 55 insertions(+), 0 deletions(-)