Patch: Fixed patch for moving RSVD/SHVXD to vfs_default

[Richard Sharpe]

On Wed, Aug 5, 2015 at 2:11 PM, Michael Adam <obnox at samba.org> wrote:
> On 2015-08-05 at 13:41 -0700, Richard Sharpe wrote:
>> On Wed, Aug 5, 2015 at 11:42 AM, Michael Adam <obnox at samba.org> wrote:
>> > On 2015-08-04 at 21:56 +0200, Ralph Böhme wrote:
>> >> On Tue, Aug 04, 2015 at 12:06:38PM -0700, Richard Sharpe wrote:
>> >> > On Tue, Aug 4, 2015 at 11:25 AM, Michael Adam <obnox at samba.org> wrote:
>> >> > > Wait a minute ... the vfs should not be fiddling
>> >> > > with smb2 create contexts! IMHO, this belongs into
>> >> > > smb2_create.c and nowhere else.
>> >> >
>> >> > Why? These are the same as Extra Create Parameters in Windows and they
>> >> > belong in NTFS, AFAICT.
>> >> >
>> >> > In addition, we already pass these to the VFS layer, and why should we
>> >> > have to add code to the SMB layer for each new ECP/Create Context
>> >> > Microsoft adds?
>> >>
>> >> iirc it was me who added the create contexts to
>> >> SMB_VFS_CREATE_FILE(). Makes sense to me.
>> >
>> > Oh, I didn't realize that. This is awful from a software layering
>> > point of view (just in my humble and possibly naive opinion...).
>> > These create contexts belong to the SMB level. The VFS represents
>> > the virtual NT file system layer. Some of the create contexts may
>> > represent things that need to have an effect to the vfs layer.
>> > In that case, I'd say we need to provide something special.
>>
>> I think you are wrong here. Create Contexts are mapped from Extra
>> Create Paramaters on Windows, and they can come from userland on
>> Windows:
>>
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff557244(v=vs.85).aspx
>>
>> Here is a list of ECPs that originate above the redirector:
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff556779(v=vs.85).aspx
>
> This is about programming device drivers. I don't quite
> understand how exactly this matches. But two comments:
>
> 1. _mapped - you say it: we should not blindly hand SMB stuff
>    down, but map only what's needed. (IMHO).
>
> 2. You are referring here to the way the redirector gets
>    extra data from driver or userland into the SMB client's
>    call of the smb create function.
>    But the code of the patch is the part where the smb server
>    takes the smb create call and prepares data to stuff into
>    the local FS create call. This is different.
>
>> Notice that last one!
>
> Yeah, the app instance id. This is a good example
> because it should on the server side only be used at the
> smb level. It should never hit the file system is my understanding.
>
> You could convince me more if you showed me the place in the
> documentation where the SMB contexts are handed into the
> local windows api call for create_file. ... :-)

In my copy of MS-SMB2 it says (Thursday, May 15, 2014):

-------------------------------
3.3.5.9.14 Handling the SVHDX_OPEN_DEVICE_CONTEXT Create Context
This section applies only to servers that implement the SMB 3.02 dialect.
If the create request has any other created contexts, the server MUST
process those create contexts before processing the
SVHDX_OPEN_DEVICE_CONTEXT.
If IsSharedVHDSupported is FALSE, the server MUST fail the request
with STATUS_INVALID_DEVICE_REQUEST.
If IsSharedVHDSupported is TRUE, the processing changes involved for
this create context are:
In the "Open Execution" phase, this request MUST be processed as
specified in [MS-RSVD] section 3.2.5.1 by providing the file name,
Open.CreateOptions, and the SVHDX_OPEN_DEVICE_CONTEXT Create Context.
In the "Successful Open Initialization" phase, the server MUST set
Open.IsSharedVHDX to TRUE.
--------------------------------

This is a little out of date, because in RSVD2 there is now a reply context.

In my copy of RSVD it says (June 30, 2015):

-----------------------------------
3.2.3 Initialization
The server MUST enumerate the shares by calling NetrShareEnum as
specified in [MS-SRVS] section 3.1.4.8. In the enumerated list, if any
of the shares have shi*_type set to STYPE_CLUSTER_SOFS, as specified
in [MS-SRVS] section 2.2.2.4, the server MUST set IsSVHDXSupported to
TRUE.
When the server is started:
 If IsSVHDXSupported is TRUE, the server MUST notify the SMB server
that it is ready to process client requests, as specified in [MS-SMB2]
section 3.3.4.25.
 The server MUST initialize ServerServiceVersion to an
implementation-specific<6> administratively configured protocol
version.
------------------------------------

I think those establish that the RSVD server is separate from the SMB
server, and that the create context is passed to the RSVD server, but
the following is also pretty clear about it:

-------------------------------------
3.2.5.1 Receiving an Open Request
Note: Some of the information in this section is subject to change
because it applies to an unreleased, preliminary version of the
Windows Server operating system, and thus may differ from the final
version of the server software when released. All behavior notes that
pertain to the unreleased, preliminary version of the Windows Server
operating system contain specific references to Windows Server 2016
Technical Preview in the Product Behavior appendix.
...

 Otherwise, the server MUST construct an
SVHDX_OPEN_DEVICE_CONTEXT_RESPONSE_V2 structure using the received
context.
--------------------------------------


-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)