s4/torture: port SMBv1 RAW-LOCK tests to SMBv2

[Steven Danneman]

> -----Original Message-----
> From: tridge at samba.org [mailto:tridge at samba.org]
> Sent: Thursday, November 26, 2009 9:17 PM
> To: Steven Danneman
> Cc: Andrew Bartlett; samba-technical at lists.samba.org
> Subject: RE: s4/torture: port SMBv1 RAW-LOCK tests to SMBv2
> 
> Hi Steven,
> 
>  > I did not investigate or fix these errors before committing the
> tests as
>  > I have zero context with the way Samba4 handles SMB2.  The tests do
> pass
>  > against both W2K8 and W2K8R2 servers.
> 
> passing against windows in this case may not be the right thing to do
> :-)
> 
> For the "lock reply on tdis" and "lock reply on logoff" tests in
> SMB2-LOCK, I think s4 was doing the right thing, and that the
> behaviour of windows is a potential data integrity bug.
> 
> The test checks that when a lock is pending and a tdis or logoff
> happens on the same tree, that the lock returns with
> NT_STATUS_OK. Imagine you had a windows app that only did some
> critical modifications on file server A once it had a lock on a
> central resource on file server B. If a tdis/logoff happens, then you
> want to be sure that you give an error response back to the lock call,
> otherwise the application might go ahead with the critical change
> thinking it has the lock when it fact it doesn't have the lock.
> 
> Or, to put it more simply, you should never say a lock call succeeded
> when it didn't.
> 
>  > While I agree that keeping 'make test' passing 100% clean at all
> times
>  > is a desirable goal, I think it's unwise to make this a pre-
> requisite to
>  > committing new, useful torture tests.
> 
> If it is a new test then it might be reasonable to add it to
> selftest/knownfail, and send a note to someone who might look at it
> for you (or as you suggest below, a bugzilla entry).
> 
> For changing existing tests then it is probably worth spending a
> little bit of time investigating the difference, as perhaps samba4 got
> it right and its a real bug that you want to fix in s3 (like with the
> two SMB2-LOCK tests I mentioned above).
> 
>  > I'd like to make these tests public as soon as they're correct, but
> I
>  > certainly don't want to hinder your verification as you're trying
to
> get
>  > a release together.  I think a good policy, and what I'll do is
mark
> the
>  > failing tests as knownfail and then file bugs for them in bugzilla
> so we
>  > can track that the issue exists and remind ourselves to remove them
> from
>  > the knownfail state when the server bugs have been addressed.
> 
> yes, that sounds good, although I'd also suggest you spend at least a
> few minutes looking to see if it really is a s4 bug or not. Sometimes
> it isn't, and it may allow you to find more bugs in the s3 code.
> 
> Cheers, Tridge

Hey Tridge,

I certainly agree that following Windows file server behavior
bit-for-bit is not desirable.  The W2K8 "pretty please" lock issue is
perfect example of that.  It's an obvious bug in Microsoft's
implementation where asking for a range which is already locked on the
same handle will unlock that range.

Though, for new tests, especially involving SMB2, we have to start with
the Windows behavior and then modify from there.

I've been dealing with this issue quite a bit in torture lately, trying
to specify server specific behavior in the most generic way, so
that the same tests can pass against multiple servers with slightly
different, yet still correct implementations.

I agree it's always beneficial to get down into the code and understand
the issue.  As always it's an issue of time not desire.

I've opened bugs 6932 and 6933 to track the two issues found in the
Samba4 server by the SMB2 lock tests.

-Steven