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: <ZONHpD7CPEWoQEq2@nanopsycho> Date: Mon, 21 Aug 2023 13:16:52 +0200 From: Jiri Pirko <jiri@...nulli.us> To: Jakub Kicinski <kuba@...nel.org> Cc: netdev@...r.kernel.org Subject: Re: ynl - mutiple policies for one nested attr used in multiple cmds Fri, Aug 18, 2023 at 10:24:47PM CEST, kuba@...nel.org wrote: >On Fri, 18 Aug 2023 20:11:16 +0200 Jiri Pirko wrote: >> Okay, you don't have good solution, do you have at least the least bad >> one? :) > >I was pondering this for the recent pp work: >https://lore.kernel.org/all/20230816234303.3786178-13-kuba@kernel.org/ >search for NL_SET_ERR_MSG_ATTR. > >I ended up hand-rejecting the attrs which I didn't want. >It's not great because the policy (netdev_page_pool_info_nl_policy) >is shared so if someone adds stuff there they'll need to know >to update all the rejects :[ > >I guess a better way to code up the same idea would be to check if tb[] >is NULL outside of expected attrs. The problem is that with devlink, there no nostrict parsing. So the like-to-be-ignored attrs if passed might error out during validation. > >Option #2 is to not use the auto-generated policy, and write the policy >by hand in the kernel with the right members. I'll go with this option for now I think. > >Option #3 is to add support for this to the YAML. With the existing >concepts we would have to redefine all levels as subsets, and then >we can override nested-attributes. A lot of typing. The YAML is really >just a slightly decorated version of the policy tables. The policy >tables in this case have to be separate. Yeah. But eventually, I think this would be needed anyway to make yaml to handle all the cases. Relying on the developer to do option #1 or #2 kinda defeats the inital yaml goal to avoid people mistakes, I think.
Powered by blists - more mailing lists