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
| ||
|
Date: Wed, 25 Feb 2015 13:03:01 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: nicolas.dichtel@...nd.com Cc: Eugene Yakubovich <eugene.yakubovich@...eos.com>, netdev@...r.kernel.org Subject: What are the intended semantics of IFLA_LINK_NETNSID? Reading through the code of rtnl_newlink I am perplexed with what your intended semantics of IFLA_LINK_NETNSID are supposed to be. My expectation was something with the same semantics IFLA_NET_NS_PID and IFLA_NET_NS_FD just a different data representation and something that could be used in more netlink messages, so you could report the network namespace where the other end of a tunnel or the the network namespace of an underlying device is. Being very slow I would expect that ILFA_LINK_NETNSID would replace dest_net or possibly net in rtnl_newlink but it does not replace either of those completely. Which causes me to think that the implementation of IFLA_LINK_NETNSID in rtnl_newlink is broken. I suspect the correct fix for rtnl_newlink is to just use IFLA_LINK_NETNSID in rtnl_link_get_net and have it be an alternative way of setting dest_net. But you may intend some different semantics that I don't understand. Eric -- 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
Powered by blists - more mailing lists