On Thu, May 11, 2017 at 08:59:27AM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > What is the usecase for this? Please don't tell me the obvious the > > answer: I just want to know what process has modified what. > > > > If the point is to know if someone else, not myself as a process, has > > modified the ruleset, that is very easy to know with the netlink > > infrastructure. > > Yes, thats in fact more important than 'know what process has modified > what', although I think it would be nice from a debug-point of view, > i.e. > > $self adds a rule > something else adds a rule at same time > > How can $self learn/know the handle assigned by kernel? > > The larger picture is to start thinking in direction of libnft, > i.e. get the groundwork going so we don't have to tell 3rd party tools > like firewalld to parse nft text output. Which is a rather pointless argument regarding the monitor changes - neither parsing 'nft monitor' nor 'nft -a list ruleset' output is a particularly good option. Assuming that there will be at least optional NLM_F_ECHO in libnftables[1], programs will receive the handles for the rules they add, probably even along with the full rule depending on the yet to define API. > Ideally, I'd like to see a mechanism where the 3rd party tool can: > 1. queue an arbitrary amount of updates (add/delete of rules, set > elements etc.) > 2. learn the unique handles assigned to these rules > so that it can identifiy/remove each one of these rules. > > Thomas Woerner suggested a way where userspace can assign unique handles > instead of the kernel but I don't like it because i found no way how the > kernel could enforce that such user-handles are unique without walking > all rules of a table for every transaction. > > But currently its impossible to delete a rule again without parsing > 'nft -a list table'. 'delete-by-name' is good of course, but, has > the same problems we have with iptables. I like that we have unique > handles that would allow to 1:1 map every rule to a uniqeue identifier. My point with all this is that delete-by-name simply doesn't exist yet, and given the obstacles it will face I guess it will take a little while until it's there. My synchronous handle output patch and these 'nft monitor' enhancements will provide an alternative at least until delete-by-name is there and actually usable. Also I don't know of a single point why not both ways should be made available - it only increases acceptance in users, which is a good thing per se. > But right now its more of a guessing game as the inserting program > doesn't see the handle(s) synchronously, just via monitor. This is only reliable if a project uses libnftnl directly and hence knows it's own portid. Cheers, Phil [1] I prefer the longer name just because it's more different to libnftnl than just 'libnft'. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
