linux-kernel - Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for RTM

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: <20180124173515.5ae2bc05@redhat.com>
Date:   Wed, 24 Jan 2018 17:35:15 +0100
From:   Jiri Benc <jbenc@...hat.com>
To:     Nicolas Dichtel <nicolas.dichtel@...nd.com>
Cc:     Christian Brauner <christianvanbrauner@...il.com>,
        netdev@...r.kernel.org, ebiederm@...ssion.com, davem@...emloft.net,
        dsahern@...il.com, fw@...len.de, daniel@...earbox.net,
        lucien.xin@...il.com, mschiffer@...verse-factory.net,
        jakub.kicinski@...ronome.com, vyasevich@...il.com,
        linux-kernel@...r.kernel.org, w.bumiller@...xmox.com,
        Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH net-next 0/3 V1] rtnetlink: enable IFLA_IF_NETNSID for
 RTM_{DEL,SET}LINK

On Wed, 24 Jan 2018 16:24:34 +0100, Nicolas Dichtel wrote:
> I wonder if it would be possible to do something in the netlink framework, like
> NETLINK_LISTEN_ALL_NSID.
> Having some ancillary data at the netlink socket level and a function like
> nlsock_net() (instead of sock_net()) to get the corresponding netns.
> With that, it would be possible, in a generci way, to support this feature for
> all netlink family.

I'm not sure it's worth the effort to do that in the framework. You'll
need modifications all the way down to the code that generates the
attributes anyway.

It's not enough to just specify that the operation should be done on a
different netns and hide that from the handlers. Take for example the
existing RTM_GETLINK. Let's say it's executed from within ns_a and
targeted to ns_b (thus IFLA_IF_NETNSID = netnsid of ns_b). Now, if
there's a veth interface in ns_b whose other end is in ns_c, there will
be IFLA_LINK_NETNSID attribute in the response. But the value has to be
netnsid of ns_c as seen from *ns_a*. If you just pretended to switch to
ns_b before invoking rtnl_getlink, it would be netnsid of ns_c as seen
from ns_b which would be wrong.

That's why 79e1ad148c844 added the tgt_net stuff.

 Jiri