[Twisted-Python] twisted linux netfilter_log protocol

[David Stainton]

In examples of Twisted UDP clients they all do this:

reactor.listenUDP(3000, MyProtocol())

What would I do instead?
reactor.addReader makes sense to me since what I have is a file descriptor,
and the reactor loop and use select or epoll find out when there is data to
read...
and call our doRead() method of the Reader.

I don't know about implementing this as a Protocol because I do not have any
equivalent to ReactorUDP. ReactorUDP's listenUDP returns a ListeningPort.
And I'm not sure how a Transport is related to my Reader... but it seems to
me
that there is some abstraction which sets callbacks for io and also calls
buildProtocol...

Would a NFLogProtocol and factory like this be usable?
Sorta like this?
https://gist.github.com/david415/6790543

If I am going to be using a Twisted Service to drop privileges after
gaining access to the fd...
How would I do this? Would I have startService() instantiate a Protocol
instance?

I don't know about the nflog file descriptor...
but the nflog generator interface is non-blocking if used like this:

    def doRead(self):
        pkt = self.nflog.next()
        while True:
            self.handlePacket(pkt)
            pkt = self.nflog.send(True)
            if pkt is NFWouldBlock: break

My nflog reader seems to work great.


On Wed, Oct 2, 2013 at 12:26 AM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:

> 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<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<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.
>
> ______________________________**_________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.**com <Twisted-Python at twistedmatrix.com>
> http://twistedmatrix.com/cgi-**bin/mailman/listinfo/twisted-**python<http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://twistedmatrix.com/pipermail/twisted-python/attachments/20131002/d93e31d8/attachment-0001.html>