[RFC] Advice on SMB client python bindings?

[Jeremy Allison]

On Mon, Nov 26, 2018 at 03:59:33PM +1300, Tim Beale via samba-technical wrote:
> Hi,
> 
> 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?

That sounds great to me !

> 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,

Yes please :-).

> 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).

I only see tests (and not many of them) using libsmb_samba_internal
from a quick glance.

It would be great to consolidate these things into one (IMHO).

Jeremy.