[cifs-protocol] [REG:116022413751567 ] Response to SVHDX_OPEN_DEVICE_CONTEXT[_V2] when shared VHDX is not supported

Jeremy Allison jra at samba.org
Thu Feb 25 19:13:41 UTC 2016


On Thu, Feb 25, 2016 at 06:55:19PM +0000, Bryan Burgin wrote:
> It would be helpful to consider "the client" as more than a single
> entity and instead as layers that are isolated.  At the SMB2 layer,
> we're just plumbing.  Some application higher up plumbed down a
> CreateFile that has a CreateContext that it faithfully sends it
> across the wire.  Why it did so and what else it might be expecting
> cannot be known to us, so we cannot know if there is behavior it
> is expecting on the server endpoint based on stuff it sent in a
> particular context.  That discussion is in a purely generalized
> scope.  Drilling into this particular context there may be some
> opportunities to make assumptions, but even in that, we should
> be careful.  The right way to resolve this, from my viewpoint,
> is to have application layers only add this context if it really
> needs the server to behave differently because of its existence
> of the context and to exclude the context when that doesn't matter.
> In some cases (i.e., it expects to open the VHDX in shared mode
> and do SCSI tunneled requests) it may very much care.
> In other situations, it may not care at all.  I'm suggesting
> that doing a blanket ignore may cause unintended consequences
> now or later that should cause us some pause now.  Possibly,
> adding a bit more intelligence than a blanket action to always
> ignore.  I have a few ideas that I'm letting percolate.

The problem is the server doesn't know "the client"
as stack intentions.

We only know they asked for something we don't
support (yet).

Now if we had no way of telling the client we
weren't giving them what they asked for I'd
agree with you - returning an error would be
the only way for the server to cope.

But we *do* tell the client we're not implementing
this - by not returning the reply blob to the
given create context we're informing the client
they didn't get the feature they wanted.

Sure - they client should only add the context if
it needs the server to use it - but the client
should also cope appropriately with the lack
of the reply context.

Essentially, the additional create contexts in
SMB2 allow an ioctl blob to be tunnelled through
a create.

As we (smbd) don't know if the underlying Samba
VFS that's loaded on the share supports this
additional context or not, all we should do is
pass the in-blobs down to the VFS module, and
then return the out-blobs returned. The underlying
smbd VFS should decide if it must fail the create
based on the in-blob contents.

tl;dr. Clients need to cope with the absense
of reply blobs to create context they asked
for in an appropriate manner.

Cheers,

	Jeremy.



More information about the cifs-protocol mailing list