Converting SMB1 tests to SMB2

[Ralph Boehme]

Hi Noel,

On 10/17/19 10:14 PM, Noel Power wrote:
> So as a first step I tried (via brute force) e.g. changing the min
> protocol definitions in the generated conf files for the test
> environments, running the tests and seeing what was failing. I then
> disabled (and/or) deleted tests to get to a point where all running
> tests pass with 'min protocol = SMB2_02'. The intention here was to
> enumerate the tests involve

I guess I would put all failing tests into selftest/knownfail.d/smb1

I'd try to generate the list with

<https://git.samba.org/?p=slow/samba.git;a=commitdiff;h=0fa5ae9d30546e46a5db9ecf7936768f69a1e957>

then running autobuild-private-security.sh on sn-devel.

Then with grep UNEXPECTED *.stdout you get a first (but incomplete) list:

<https://git.samba.org/?p=slow/samba.git;a=commitdiff;h=4e2788f7d494b6e402784d217f37c08b985f3d7a>

I noticed a crash in smbtorture is triggered by a test, so there's
likely some iterations needed to manually filter out tests that induce
crashes.

> 
> I tried to list the tests for each environment (with/without) the
> changes, I am attaching the diff of tests here (sorted by test env) be
> aware there maybe some minor errors in there, the diffs were ugly and
> needed to be tweaked by hand and I most likely made some minor
> mistakes.  The build (with brute force changes) to do this can be found 
> https://gitlab.com/samba-team/devel/samba/commits/squash-smb2-only
> 
> My plan is to first move all of these tests identified above to suitable
> smb1 environments (e.g. nt4_dc_smb1) etc. So we
> 
> a) can clearly see the tests that need to be deleted/ported/fixed

I guess I would take the knownfail list as basis to for fixing stuff.
Whenever commits change/fix things you also update the knownfail list,
so make test always passes with each commit.

I don't think the additional work of letting the tests use a different
testenv really helps. We'll just have to go through the knownfail list
and look at each failing test to see what's needed to fix it.

> 
> b) we can immediately delineate the smb1 vs >= smb2 tests  and be sure
> we don't lose anything along the way
> 
> I've started as a proof of concept
> https://gitlab.com/samba-team/devel/samba/commits/separate-smb1-tests to
> migrate tests
> 
> Does this make sense? I expect it will be a bit time consuming to
> separate the tests (when some may be just deleted) so I wonder do others
> think it is worth it (personally I do) But I'd like some other opinions
> before continuing down that road :-)
> 
> In the end I suppose the tests that fail will fall into 1 of the
> categories below
> 
> a) a test that tess > SMB1 only functionality or messages (probably these
> can be just deleted)

yes.

> b) a test that tests SMB1 functionality but doesn't and should test the
> same functionality  >=SMB2 (needs porting)

yes.

> c) A test that maybe isn't essentially SMB1 or greater but that perhaps
> fails with the new defaults for some reason. For example;
> 
>    + a blackbox test scripts might have some parts working with e.g. NT1
> mixed with other bits that are using >= SMB2 (needs rewriting)
> 
>    + a python test may have mixed SMB1 & >=SMB2 tests in the same test
> module (needs rewriting)
> 
>    + some test you would expect should pass with the new min protocol
> but doesn't (therefore needs investigation)

Do we have such beasts? Heavens!

> So, if anyone can immediately identify say any tests we can just delete
> or port from the attached list of test diffs, that would be useful :-)
> Could save us some time digging.

I guess one of the first things I'd look as is all the torture tests
that run against both nt4_dc and ad_dc. I guess for most it's ok to just
run them against either one.

Everything else probably has to be assessed one by one.

Note that tests ported from smb1 to smb2 must also pass against Windows.

Fwiw, once you get to the base.delaywrite tests be warned, that Windows
behaviour is different between Windows 2003 (which is what Samba
implements) and Windows 2008 or newer. It's also different between SMB1
and 2, see

https://bugzilla.samba.org/show_bug.cgi?id=13594

-slow

-- 
Ralph Boehme, Samba Team                https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG-Fingerprint   FAE2C6088A24252051C559E4AA1E9B7126399E46