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
| ||
|
Message-ID: <79a6e186763b199b3fd28ef0dc0e67b3698fea89.camel@sipsolutions.net> Date: Fri, 26 Apr 2019 21:46:33 +0200 From: Johannes Berg <johannes@...solutions.net> To: Pablo Neira Ayuso <pablo@...filter.org> Cc: netfilter-devel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH RFC 4/4] netfilter: nf_tables: add netlink description On Fri, 2019-04-26 at 21:37 +0200, Johannes Berg wrote: > You're now thinking of the "policy ID" I assigned for the wire format as > the object ID, but really that's not what it is. The object ID that > you're looking for is the attribute type of the nested attribute. > > So if you have > > struct nla_policy nested_policy[...] = { ... }; > > struct nla_policy policy[...] = { > [MY_ATTR] = NLA_POLICY_NESTED(nested_policy), > }; > So if we extend this, say like this: struct nla_policy policy[...] = { [MY_ATTR] = NLA_POLICY_NESTED(nested_policy), [MY_OTHER_ATTR] = NLA_POLICY_NESTED(nested_policy), }; then you could perhaps argue that having an object ID makes sense, and assigning the same object ID to MY_ATTR and MY_OTHER_ATTR would make sense? Of course, my could would assign this the same (temporary) policy ID, but there can be no reliance on the policy ID beyond what's needed at runtime to map the attribute to the nested policy. You still see at runtime that these have the same policy (since they have the same policy ID), but at the same time presumably there was a reason to have MY_ATTR and MY_OTHER_ATTR, so perhaps the semantics are different even if the attributes are the same, as could perhaps be expected if you have a SET and a CLEAR attribute (MY_ATTR and MY_OTHER_ATTR respectively) and the contents you give has the same policy, but different logic? Basically, I just didn't consider this case to be significant enough to manually and assign stable IDs of some sort, when we already have them in the form of the attribute type. johannes
Powered by blists - more mailing lists