readx and CAP_LARGE_READX
James Peach
jpeach at samba.org
Fri Dec 8 00:26:17 GMT 2006
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
More information about the samba-technical
mailing list