readx and CAP_LARGE_READX

[James Peach]

On Dec 7, 2006, at 4:08 PM, tridge at samba.org wrote:

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

OSX can (or will). I believe the Thursby client does too.

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

Thanks. The patch I posted earlier did this, but not very nicely.

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

Are you sure that this test is not triggering a DoS detection  
mechanism? In a former life I was involved in some work on the sunrpc  
libraries that rejected activities like that on that basis that it was  
almost certainly a malicious client.

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

Does it still give NT_STATUS_ACCESS_DENIED independently of whether  
you are drip-feeding the data?

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

OK, that sounds sane.

--
James Peach | jpeach at samba.org