Re: [NETFILTER 06/6]: Restore {ipt,ip6t,ebt}_LOG compatibility

[Patrick McHardy <kaber@trash.net>]

Gregor Maier wrote:
> Patrick McHardy wrote:
> 
>>>Restore compatiblity by using the old log functions by default and only use
>>>the nf_log backend if the user explicitly said so.
>>>
> 
> 
> ipt_LOG still registers itfself as nf_log logger in init(). Good, so
> since conntrack can now log.
> 
> Problem: no anthoer loggers can register for PF_INET right away. They
> must unregister the ipt_LOG logger first. Then they can register
> themselves. I don't like the idea of modules and esp. userspace apps
> unregistering handlers from other modules. First Come First Serve.

Exactly, this is how it works now, if we forget about the UNBIND
operation of nf_log (which I'm not a fan of either). Ideally the
log backends should be stackable.

> When ipt_LOG doesn't register a nf_log logger, then the problem would
> not arise, although the conntrack code could not log anything until some
> other logger has been registered (since conntrack uses nf_log_packet).
> 
> 
> 
> Maybe nf_log should have two handlers for each PF:
> - One handler for loginfo.type == NF_LOG_TYPE_LOG. Which can be provided
> by ipt_LOG.
> - One handler for loginfo.type == NF_LOG_TYPE_ULOG, for which
> nfnetlink_log strongly qualifies.
> 
> 
> So, as long as ipt_LOG is loaded, conntrack et.al. can log to syslog as is.
> 
> If netlink_log is used additionally, (as handler for TYPE_ULOG),
> conntrack et.al. won't notice it.
> 
> If _everything_ should be logged to userspace, then netlink_log could
> also unregister the TYPE_LOG handler and register itself as handler for it.

I think stackable log backends are the cleanest solution for this.