[Twisted-Python] twisted linux netfilter_log protocol

[Phil Mayers]

On 10/02/2013 07:14 AM, David Stainton wrote:
> Hi,
>
> I am wondering how I should combine various twisted interfaces
> in a way that makes sense. It probably shows here... that I'm new to
> twisted.
>
> The Linux iptables can log packets to the netfilter_log which can give
> access to user space.
> I wrote a simple twisted Reader (IReadDescriptor implementation) that is
> working functional code...
> https://gist.github.com/david415/6789612
>
> But since these are packets it returns... should I implement a "read
> only Protocol"?

Well, if your transport is not writable, just don't implement that - 
Exceptions will be raised if you mistakenly try to write, so nothing bad 
will happen.

> The protocol's dataReceive() method could be called from the
> NFLogReader's doRead() method.

Since they're packets it should really be a DatagramProtocol and call 
datagramReceived.

> Does this mean that NFLogReader would be responsible for calling
> buildProtocol to construct the NFLogProtocol?

Typically a factory is responsible for calling buildProtocol, but in 
most datagram uses, there is only one protocol instance per port, so you 
just instantiate it. See e.g.

http://twistedmatrix.com/documents/current/core/howto/udp.html

> In the normal Twisted examples the buildProtocol seems to be called from
> the react loop..
> Should I pass the protocol factory and the reader to the service?

Sorry I don't know what this means.

>
> If I want to drop privileges right after retrieving the filedescriptor
> for netfilter_log, shall I use a Twisted Service/Application to drop the
> root privs to a non-superuser?

That would be the "Twisted" way of doing it, yes.

> Should the privileges be dropped by the privilegedStartService() method?
> The manual says that method is for preparing to drop services...
>
> What I want out of all of this is the most high performance and general
> solution to utilizing netfilter_log in twisted...

Couple of general points:

The nflog_cffi code is... hard to read. But it's not obvious to me that 
it sets the FD to nonblocking anywhere, or that it's (frankly weird) 
generator construct will actually yield the "nonblock" marker object at 
the right times. You might want to test this.

On a different note, a colleague wrote some code to process the IPQUEUE 
target of iptables a while back. This code did something similar to your 
example above, but it didn't bother integrating with the 
protocol/factory machinery, and you could consider whether it makes 
sense to do so - unlike a TCP or UDP port, you're unlikely to ever have 
 >1 nflog "connection" per-process, so it's not obvious that using the 
full generality of the factory/protocol machinery is appropriate.

However if you do that, I would just copy what Twisted does for UDP; 
don't model it on TCP.