readx and CAP_LARGE_READX

[tridge at samba.org]

James,

 > cifsdd is stupid by design. I wrote is because I wanted a tool to give  
 > me precise control over how I/O is done on the wire. If windows  
 > doesn't implement the SNIA readX behaviour, then I am perfectly happy  
 > for cifsdd to not work.

ahh, ok, I had misunderstood the purpose of the tool then. What you've
really done is written a command line interface to the libcli/raw
library (I designed the raw library with the same philosophy as you
had for cifsdd - that it would do exactly whats asked of it, even if
the server can't handle it).

 > However, Samba3 does implement the SNIA readX behaviour (and there are  
 > non-Windows clients in the wild that take advantage of this).

which clients take advantage of this, apart from cifsdd?

 > I'm arguing that the Samba4 libcli should let me take advantage of
 > the Samba3 implementation if it is there.

ok - I agree now that I understand the purpose :-)

I'll look at changing libcli to make this work.

 > For cifsdd I try to ask libcli to negotiate a buffer size large enough  
 > for the size of the I/Os I want to do. IIRC I proceed to ignore the  
 > buffer size that was actually negotiated, so it sounds like this  
 > "behaviour" could bite me.

yes, it probably will. 

btw, if you want to investigate this behaviour, this is what I did to
discover why w2k3 is behaving as it is. I setup a SMBwriteX with a bit
larger write than the negotiated buffer size, connected to a w2k3 DC,
with signing enabled. Then I sent the writex, but didn't send all the
bytes of the request. I sent just the header and the first part of the
data, then sent the rest of the data 1 byte at a time, with a small
delay (a fraction of a second) between the bytes. I watched with a
sniffer.

What you see is that the NT_STATUS_ACCESS_DENIED (the normal signing
error) comes back as soon as you have sent more bytes than the
negotiated buffer size. It comes back _before_ you have sent the full
request. This means that the signing must be being done on only the
partial request, which means it's a bug in how much data they pass to
the signing function, rather than a bug in the signing code itself.

 > Maybe I should to add an argument to cifsdd to relax it's I/O  
 > behaviour. Something that means "try to do what I told you, but play  
 > it safe so things will actually work".

I think that should probably be the default actually, and have an
option to force it to try operations that will fail with windows
servers if the user wants them. Or have an environment variable to
enable that behaviour.

Cheers, Tridge