netdev - Aw: Re: [RFC 1/1] net/tun: fdinfo to relate TAP/TUN network interfaces unambiguously with their serving processes

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] [day] [month] [year] [list]

Date:   Tue, 26 Mar 2019 14:03:20 +0100
From:   "Harald Albrecht" <Harald.Albrecht@....net>
To:     "Stephen Hemminger" <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org
Subject: Aw: Re: [RFC 1/1] net/tun: fdinfo to relate TAP/TUN network
 interfaces unambiguously with their serving processes

> Gesendet: Freitag, 22. März 2019 um 16:44 Uhr
> Von: "Stephen Hemminger" <stephen@...workplumber.org>
> An: "Harald Albrecht" <Harald.Albrecht@....net>
> Cc: netdev@...r.kernel.org
> Betreff: Re: [RFC 1/1] net/tun: fdinfo to relate TAP/TUN network interfaces unambiguously with their serving processes
>
> The /proc formats are fixed and legacy at this point. Please don't add anything new.
>
> Why not add values to sysfs (one value per file)?

This leaves me completely lost now, as I'm unclear as to how the "link" between a /sys/class/net/$NIF/ TAP/TUN network device and its serving process(es) could look like -- can you please help me here?

What I need is to relate TAP/TUN network interfaces with their serving processes -- please note the plural here, as due to passing fd's down to child processes. So would it then make sense to add a new /sys/class/net/$NIF/taptun_owner DEVICE_ATTR which returns a (tabbed) list of serving process PIDs?

If yes to returning a list of serving process PIDs, then how to I get all the PIDs? With my really limited understanding of things in this field I would need to scan all processes for their fd's in order to see which ones are referencing the $NIF TAP/TUN in question. This would be exactly what I'm currently doing in user space in my diag software, but now I would need to move this into the kernel into sysfs territory, is that what you are suggesting? To me the road down the fdinfo path had the advantage that it is keeping the specific app semantics out of the kernel, that is, searching for serving processes in kernel land -- but I might be misunderstanding this.

Am I completely on the wrong track here with my question about listing the serving processes; is there a better way? As I said above, I'm (not only slightly) lost at the moment...

-- Harald