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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ