On Thu, Jan 09, 2014 at 06:40:25PM +0100, Pablo Neira Ayuso wrote: > Hi Patrick, > > On Wed, Jan 08, 2014 at 08:58:13PM +0000, Patrick McHardy wrote: > > commit 8ca6730e9c8fd59d8a03ae505777a8a6b97898b1 > > Author: Patrick McHardy <kaber@xxxxxxxxx> > > Date: Wed Jan 8 20:57:11 2014 +0000 > > > > nftables: fix surpression of "permission denied" errors > > > > ntroduction of batch support broke displaying of EPERM since those are > > generated by the kernel before batch processing start and thus have the > > sequence number of the NFNL_MSG_BATCH_BEGIN message instead of the > > command messages. Also only a single error message is generated for the > > entire batch. > > > > This patch fixes this by noting the batch sequence number and displaying > > the error for all commands since this is what would happen if the > > permission check was inside batch processing as every other check. > > One error message per line can be too much if we have a big batch, > perhaps we can just point to the first rule in the batch and print > something like: "7 error suppressed.", similar to syslog, where 7 is > the number of rules that follow up after EPERM message. Well, this was done to stay consistent with any other error type. We could compress similar errors, but there are a few things to consider. One is that it might be hard to point to the correct spot(s) in the error message. Also the output format was chosen to be similar to gcc so f.i. vi could easily jump to rules causing errors in a file. For now I think we should apply this patch, which will treat EPERM like any other error, and then work on something to reduce the output. > BTW, with really really big batches, the kernel may fail to allocate > the acknowledgment. We discussed this already with David, and he > thinks it doesn't make sense to send such a big message back to > sender. We can add: > > void netlink_ack_len(struct sk_buff *in_skb, struct nlmsghdr *nlh, > int err, int len) > > where len specifies the length would be the original netlink header + > nfnetlink header, so the rules are not sent back to userspace. > > Let me know, thanks! Why would it depend on the size of the batch? The errors are allocated for every single message *within* the batch. I agree though that if we can allocate a smaller message without the full contents, this is still better than using sk_err. But I guess that should simply be fallback behaviour of netlink_ack() instead of specifying a length. -- 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
