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: <b8b4a8e3-b574-cc9c-98d1-39911625ad37@6wind.com>
Date:   Thu, 25 Jan 2018 15:20:59 +0100
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Jiri Benc <jbenc@...hat.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

Le 24/01/2018 à 17:35, Jiri Benc a écrit :
> 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.
Hmm, I don't agree. For me, it would be the correct answer. If user has a socket
in ns_a and targets a RTM_GETLINK in ns_b, the answer he gets should be like if
it was done in ns_b.
This is already the case with messages received with NETLINK_LISTEN_ALL_NSID,
there is no reason to do something different.


Regards,
Nicolas