On Thu, Mar 24, 2022 at 02:48:22PM -0400, Tom Talpey wrote:
On 3/24/2022 12:23 PM, Jeremy Allison wrote:
On Thu, Mar 24, 2022 at 11:04:30AM -0400, Tom Talpey wrote:
On 3/23/2022 1:29 PM, Enzo Matsumiya wrote:
Hi Tom,
On 03/19, Tom Talpey wrote:
What server is returning this unsigned response? Assuming it's Windows,
that is either a doc bug or (arguably) a server bug, and should be
reported before deciding how to address it here.
It's a NetApp ONTAP 9.5P13. We've identified it's also setting wrong
signatures on READ responses with STATUS_END_OF_FILE.
Our tests against Windows Server 2019 showed it to behave ok, so it
looks like something on NetApp side.
In this case I don't think it is appropriate to apply the suggested
patch. Allowing unsigned or invalidly signed responses will greatly
reduce security. I'll be interested if NetApp provides any information.
Welcome to our world :-). Doing:
git log|grep -i NetApp|wc -l
shows 32 instances (some are commit messages with NetApp in
them two or more times so the number is probably a little
smaller than 32) of commits in Samba especially to
deal with NetApp bugs :-).
That's a lot of client bugfixes :-).
Well, it could be argued that this is prolonging the bad behavior.
The NFS client maintainer's approach is the opposite - if the server
is violating the protocol, he holds the line and will not change
the client. I know, I know, it's all in how each person sees it. :)
It's all a question of leverage. A Microsoft behavior defines
the protocol, even if it's an inadvertant bug.
For NetApp, people using cifsfs, libsmbclient or our client tools just
want the damn thing to work. NetApp only (as far as I know)
test against a Microsoft client, so we have zero leverage here.
Sucks, but as I said, "Welcome to our world" :-).
