Best practices: Adding Persistent Handle support

[Tom Talpey]

> -----Original Message-----
> From: Christopher R. Hertel [mailto:crh at samba.org]
> Sent: Tuesday, June 6, 2017 5:53 PM
> To: Tom Talpey <ttalpey at microsoft.com>; Stefan Metzmacher
> <metze at samba.org>
> Cc: samba-technical at lists.samba.org
> Subject: Re: Best practices: Adding Persistent Handle support
> 
> Tom, Metze, et. al.,
> 
> Tom:
> 
> Question for you:  If SMB2_GLOBAL_CAP_PERSISTENT_HANDLES is clear on the
> connection, can a share still send
> SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY?

Well, in a trivial sense yes because the SMB3.x server will only return the persistent
handles capability to clients that sent the same flag in the negotiate. So, the example
is an SMB2.x client, which would never do that (because the bit only exists in 3.x).

However, such a client would also ignore the continuous availability bit. The concern
I would foresee is a 3.x client which might process it. I would consider that an untested
scenario, not expressly forbidden in the protocol. A risky design decision for you to
depend on, perhaps.

> 
> That is, are the two completely independent or can the share indicate CA
> even if the connection doesn't provide Persistent Handles?
> 
> Everyone:
> 
> Here's what I'm thinking...
> 
> Two new smb.conf parameters:
>   * global persistent handles (G) = Yes|Auto|No
>   * continuous availability (S)   = Yes|Auto|No
> 
> The first of those would control the
> SMB2_GLOBAL_CAP_PERSISTENT_HANDLES bit,
> and the second would control (per share) the
> SMB2_SHARE_CAP_CONTINUOUS_AVAILABILITY bit in the Tree Connect
> response.
> 
> The default, in both cases, would be Auto, and here's how it would work:
> 
> global persistent handles:
>   Yes  = SMB2_GLOBAL_CAP_PERSISTENT_HANDLES will be set by the server to
>          indicate that the server supports Persistent Handles.
>   Auto = The default.  This behaves just like "No" under normal
>          circumstances.  More in a moment.
>   No   = SMB2_GLOBAL_CAP_PERSISTENT_HANDLES will not be set by the
> server.
> 
>   In the case of Auto, the VFS module would be permitted to change the value
>   to "Yes" at run-time.  Basically, SMB2_GLOBAL_CAP_PERSISTENT_HANDLES
> would
>   be disabled unless this value is set to Auto and a VFS module enables it.

Ok, I will definitely say that changing the value at runtime is dangerous. Consider
a connection loss scenario - the client will reconnect and renegotiate, finding the
server capabilities (and therefore handle state) to have changed. Or consider a
multichannel connect - the channels could have different capabilities!

I believe that secure negotiate will protect these, but I'd have to think through
the details. If it does protect the scenario, the result will be failed connections.

Tom.


> 
> continuous availability:
>   Essentially the same behavior, but at the Share level.  The only
>   outstanding question is whether or not the setting of 'global persistent
>   handles' will impact the interpretation of 'continuous availability'.
> 
> I'll go work on some code now, but let me know what you think.
> 
> Chris -)-----
> 
> 
> > * Monolithic: "One Big Rock" :-)
> 
> Yeah...  I knew that, actually!  ;-)