[RFC] Advice on SMB client python bindings?

Tim Beale timbeale at catalyst.net.nz
Mon Nov 26 02:59:33 UTC 2018


Currently certain samba-tool commands don't work if SMBv1 is disabled on
the server [1]. I'm trying to fix this, and just wanted to check if
anyone has any input before I go too far down the wrong path.

Basically the problem is the current SMB python bindings that we're
using (pysmb.c) don't have proper SMBv2 support.

To start with, I looked at the changes Metze made to the source4 RPC
code to support SMBv2 (i.e. commit 4422f7382aad309) and tried to use the
same approach. I got a SMBv2 connection established, but quickly
realized that although source4 libcli contains SMBv2 code, there's no
common API to handle *either* a SMBv1 or SMBv2 connection. The SMBv1 and
SMBv2 code use different data structures, and so an extra layer would be
need to be added to the source4 libcli code to handle this.

It seems like the source3 libsmb code has already solved this problem
(i.e. the smbXcli_conn_protocol(cli->conn) >= PROTOCOL_SMB2_02 checks).
So now I'm looking at moving the python bindings into the source3 tree
instead, so we can use the source3 SMB client library code underneath.
Does this approach sound reasonable?

Finally, I noticed there's some existing source3 python bindings
(pylibsmb.c, aka libsmb_samba_internal), however, they don't really
appear to be used. Should I consolidate this code with what I'm
changing, so we have a single set of SMB client python bindings? If so,
does anything actually rely on libsmb_samba_internal? (Removing the
.get_oplock_break API so we can use the synchronous SMB client APIs
would make my life a lot easier).

Thanks for your help.


[1] https://bugzilla.samba.org/show_bug.cgi?id=13676

More information about the samba-technical mailing list