Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > On Wed, May 10, 2017 at 01:27:24PM +0200, Florian Westphal wrote: > > While most programs set it to their process id there is no guarantee. > > Its just a (unique) 32 bit identifier. > > It's actually the kernel that decides what portID the socket gets > IIRC. For the first socket it uses the process ID, then for follow up > sockets, it just looks for a spare ID in the negative range of the 32 > bit, if my memory serves well. Argh, yes, of course... > > Afaics one has to use /proc/net/netlink to map the portid to the inode > > and then walk /proc/*/fd/* to find the socket with that inode. > > > > Perhaps there is a simpler way, maybe you can check what ss is doing > > and what info can be obtained via netlink diag. > > I wouldn't be surprise if we need more kernel infrastructure to deal > with this. Parsing /proc for a netlink thing is definitely not ideal. Yes. From nft monitor point of view the most easy solution would be if the process id (or even the name?) would be sent back to userspace in a netlink attribute. Do you think we can extend nf_tables to include get_task_comm() name and/or pid when/if we send update notifications? (The pid is actually not that useful as process might have exited already). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
