On Tue, Feb 18, 2014 at 10:43:20AM +0100, Pablo Neira Ayuso wrote:
> On Tue, Feb 18, 2014 at 09:33:11AM +0000, Patrick McHardy wrote:
> > On Tue, Feb 18, 2014 at 10:28:11AM +0100, Pablo Neira Ayuso wrote:
> > > On Tue, Feb 18, 2014 at 02:03:55AM +0000, Patrick McHardy wrote:
> > > > On Tue, Feb 18, 2014 at 02:10:07AM +0100, Pablo Neira Ayuso wrote:
> > > > > On Tue, Feb 18, 2014 at 12:18:38AM +0100, Arturo Borrero Gonzalez wrote:
> > > > > > +static int netlink_events_table_cb(const struct nlmsghdr *nlh, int type,
> > > > > > + struct netlink_ev_handler *evh)
> > > > > > +{
> > > > > > + struct nft_table *nlt;
> > > > > > + uint32_t family;
> > > > > > + char buf[4096];
> > > > > > +
> > > > > > + nlt = nft_table_alloc();
> > > > > > + if (nlt == NULL)
> > > > > > + memory_allocation_error();
> > > > > > +
> > > > > > + if (nft_table_nlmsg_parse(nlh, nlt) < 0) {
> > > > > > + netlink_io_error(evh->ctx, evh->loc,
> > > > > > + "Could not parse table: %s",
> > > > > > + strerror(errno));
> > > > >
> > > > > I think you should exit on parsing errors.
> > > >
> > > > I'm not so sure for event reporting. We should abort reporting the current
> > > > event, sure. But I don't see why we shouldn't continue listering for further
> > > > events.
> > >
> > > I think if we fail to parse anything it means that there's some bug
> > > that need to be fixed, eg. someone changed the length of an attribute
> > > so validation fails. I think stopping there should help us to get
> > > people reporting problems.
> >
> > Well, it depends on what exactly we couldn't parse or handle. Basic things
> > like table names etc. can of course trigger a fatal error. But unknown
> > expression types shouldn't cause an error.
>
> As i said, unknown netlink attributes are skipped.
>
> That function is not building *any* struct expr *, it's just
> generating the libnftnl nft_table object that is used to obtain the
> internal table object in a later stage. If it fails there's something
> that need to be fixed in that code.
Sure, just wanted to be clear about which types of errors may cause
a fatal error.
--
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
