Project

General

Profile

Feature #9875

SMB client connection setup rework

Added by Gordon Ross over 2 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2018-10-06
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

In preparation for #9735 (Need to provide SMB 2.1 Client) I found it useful to separate out some of the rework of how the SMB client sets up new connections.
This also fixes a minor bug (SMB client tries to connect twice) but most of this work is an architectural enhancement needed by later work.

#1

Updated by Gordon Ross over 2 years ago

While working on adding SMB2 support to the SMB client, I found the existing design to be somewhat inconvenient. This issue tracks a minor redesign of SMB client connection setup. this is a separate issue from "add SMB2" (#9735) because it's testable independently from that work, and changes in small, testable chunks are almost always better than larger chunks.

The current SMB client design implements connection setup doing as much as possible in user space. That's normally (in general) a good approach, but in this design it causes some code duplication because it implies dealing with SMB messages both in the user level library and in the kernel. That code duplication wasn't excessive with just SMB1 messages, but I found that once I started adding SMB2 support, it became apparent that it would be easier to change that design so that SMB messages (SMB1 or SMB2) are handled only in the driver.

In the new design, connection setup is still driven by the user-level library (instantiated in the smbiod service program), but the actual SMB message handling is all in the kernel driver. The user level code creates an IO Deamon (IOD) thread which calls a series of ioctl functions to sequence the driver through SMB (or SMB2) negotiate, SMB (or SMB2) session setup. After that point, the design is the same as before. If the session setup is successful, the IOD thread enters the driver via a "work" ioctl and stays there as long as the connection is usable and needed.

Also unchanged is where the authentication objects are built and parsed, with only the transport of those objects changed in this design. Previously, the library code extracted an incoming authentication object (SPNEGO) from an SMB reply, built an outgoing object, wrapped it in an SMB session setup request and sent it out. In the new design, the driver extracts the authentication object from the SMB (or SMB2) message and copies it out into a buffer provided by the user-level library in the ioctl call. The library code builds a response authentication object and passes that buffer to the next ioctl call, which then (in the driver) wraps that auth. object in an SMB (or SMB2) session setup request and sends it out.

One simplification was made in SMB1 for this design: In SMB1 we used to allow either "extended security" (SPNEGO) or old-style (non-extended) authentication. We could support SMB1 non-extended in this design, but that would add a bunch of complication and it's not needed to talk to any reasonably modern server, so this implements only "extended-security" in SMB1. (In SMB2 there is only extended security, so this is never an issue there.)

#2

Updated by Electric Monk about 2 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100

git commit 40c0e2317898b8c774791bdc2b30bd50111ab1fa

commit  40c0e2317898b8c774791bdc2b30bd50111ab1fa
Author: Gordon Ross <gwr@nexenta.com>
Date:   2019-03-14T14:38:30.000Z

    9875 SMB client connection setup rework
    Reviewed by: Evan Layton <evan.layton@nexenta.com>
    Reviewed by: Matt Barden <matt.barden@nexenta.com>
    Approved by: Joshua M. Clulow <josh@sysmgr.org>

Also available in: Atom PDF