libxtwrapper in 2019 - Githubissues

ldx / python-iptables

Python bindings for iptables

731 stars 183 forks source link

libxtwrapper in 2019 #276

Closed drzraf closed 4 years ago

drzraf commented 5 years ago

This library makes system awkward and a shared object living around in places like /usr/lib/python3/dist-packages/libxtwrapper.cpython-37m-x86_64-linux-gnu.so. This is obviously outside standard ldconfig library paths and it the reason for:

extra *find_library* wrappers
extra documentation
extra packaging scripting

1. Is this wrapper still needed?

get_kernel_version could be replaced by native python platform.uname().release
There is no visible reason to look for ip4tc, ip6tc or iptc libraries outside standard paths
Why are wrap*() function necessary?

2. If it's actually needed, why this library couldn't live into /usr/lib/ ?

It would be found out-of-the-box without further packaging tweaks.
Current packaging does not make it work because Debian-based distribution do NOT come with no /etc/ld.so.conf.d/ file. I'd say that #193 (e947af15f0cfe3) didn't completely fixed the distribution.

ldx commented 5 years ago

get_kernel_version could be replaced by native python platform.uname().release

Correct.

There is no visible reason to look for ip4tc, ip6tc or iptc libraries outside standard paths

Some people install iptables in a non-standard location, alongside an existing system install.

Why are wrap*() function necessary?

Long story short: the iptc libraries have some limitations (most notably error handling) we need to work around.

Does this answer your questions?

drzraf commented 5 years ago

Thank you for the answer. If some people install iptables in a non-standard location then they could rely on LD_PRELOAD as well and this does not quite explain why this library wouldn't live in a standard location. Still about the wrap*() there are no so many comments and I didn't find more explanation from the history nor reference to a mailing-list thread.

Are these function working around (known) bug(s) that may have been fixed upstream in the meantime?
What could possibly fail without this wrapper? Have you envisioned making this whole wrapping optional?
The wrap*() are passed the ct.CFUNCTYPE() and from what I understand these setjmp serve as failsafe runtime checks for library's function presence. Sound strange that no other option exist.

ldx commented 5 years ago

There is a callback in the iptables library called exit_err(). We override this so that instead of just printing out an error and exiting (the default behavior in iptables), we can transfer back control via setjmp()/longjmp(). The function wrappers set up the target to which control will be transferred back to when an error occurs in the iptables C library.