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: <1ff2e97e-003f-e6b4-d724-c42449fde221@6wind.com>
Date:   Wed, 21 Sep 2022 11:11:19 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Hangbin Liu <liuhangbin@...il.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Ido Schimmel <idosch@...dia.com>,
        Petr Machata <petrm@...dia.com>,
        Florent Fourcot <florent.fourcot@...irst.fr>,
        Nikolay Aleksandrov <razor@...ckwall.org>,
        Guillaume Nault <gnault@...hat.com>
Subject: Re: [PATCH net-next] rtnetlink: Honour NLM_F_ECHO flag in rtnl_{new,
 set}link


Le 21/09/2022 à 05:07, Hangbin Liu a écrit :
> Netlink messages are used for communicating between user and kernel space.
> When user space configures the kernel with netlink messages, it can set the
> NLM_F_ECHO flag to request the kernel to send the applied configuration back
> to the caller. This allows user space to retrieve configuration information
> that are filled by the kernel (either because these parameters can only be
> set by the kernel or because user space let the kernel choose a default
> value).
> 
> This patch handles NLM_F_ECHO flag and send link info back after
> rtnl_{new, set}link.
> 
> Suggested-by: Guillaume Nault <gnault@...hat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
> ---

[snip]

> @@ -3336,9 +3381,9 @@ static int rtnl_newlink_create(struct sk_buff *skb, struct ifinfomsg *ifm,
>  		return PTR_ERR(dest_net);
>  
>  	if (tb[IFLA_LINK_NETNSID]) {
> -		int id = nla_get_s32(tb[IFLA_LINK_NETNSID]);
> +		netnsid = nla_get_s32(tb[IFLA_LINK_NETNSID]);
>  
> -		link_net = get_net_ns_by_id(dest_net, id);
> +		link_net = get_net_ns_by_id(dest_net, netnsid);
>  		if (!link_net) {
>  			NL_SET_ERR_MSG(extack, "Unknown network namespace id");
>  			err =  -EINVAL;
> @@ -3382,6 +3427,17 @@ static int rtnl_newlink_create(struct sk_buff *skb, struct ifinfomsg *ifm,
>  		if (err)
>  			goto out_unregister;
>  	}
> +
> +	if (nlmsg_flags & NLM_F_ECHO) {
> +		u32 ext_filter_mask = 0;
> +
> +		if (tb[IFLA_EXT_MASK])
> +			ext_filter_mask = nla_get_u32(tb[IFLA_EXT_MASK]);
> +
> +		rtnl_echo_link_info(dev, NETLINK_CB(skb).portid, nlmsg_seq,
> +				    ext_filter_mask, netnsid);
=> netnsid, ie IFLA_LINK_NETNSID has nothing to do with IFLA_TARGET_NETNSID.
Link netns is used for x-netns interface like vlan for example. The vlan iface
could be in a netns while its lower iface could be in another netns.

The target netns is used when a netlink message is sent in a netns but should
act in another netns.

Regards,
Nicolas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ