netdev - Re: [PATCH] unix: show socket peer if no addr is given in /proc/net/unix

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140108.010043.2192738470649350132.davem@davemloft.net>
Date:	Wed, 08 Jan 2014 01:00:43 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	yamato@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] unix: show socket peer if no addr is given in
 /proc/net/unix

From: Masatake YAMATO <yamato@...hat.com>
Date: Wed,  8 Jan 2014 14:18:08 +0900

> Path field of /proc/net/unix is empty if an address is not given
> to a socket. Typical way to create such socket is calling
> socketpair. The empty fields make it difficult to understand the
> communication between processes. e.g. lsof cannot resolve the role of
> file descriptors well.
> 
> This patch fills the empty fields with unix_peer.
> 
> Signed-off-by: Masatake YAMATO <yamato@...hat.com>

You cannot change the format of a procfs file without potentially
breaking some application which might interpret the output.

In this case an application might be looking for an empty field
as meaning the sockhad has no given address.

I cannot apply this patch.  People have repeatedly tried making
changes to these networking socket procfs files, and I really wish
people would stop trying to do so.

If you want specific pieces of new information, extend the socket
dumping facility that is actually extensible in a way which will not
break existing applications, and that's netlink.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html