POSIX Extenstions for SMB2/3. An initial proposal.

Richard Sharpe realrichardsharpe at gmail.com
Wed Jun 10 08:32:48 MDT 2015


On Tue, Jun 9, 2015 at 7:52 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> Hi folks,
>
> At Samba XP Steve French and I got to talking about POSIX extensions
> for SMB2/3. We came up with an interim proposal and then Steve and I
> started prototyping some things. Steve worked on the CIFS FS in Linux
> and I made some mods to Samba to get a proof of concept of the Samba
> changes required. It all looked feasible so I thought I would post
> this here for comments.
>
> The essentials are:
>
> 1. A Client will open the root of a share and use a CREATE CONTEXT to
> ask the server what it supports. It can also ask for a POSIX open at
> that time. If the server does not understand the CREATE CONTEXT it
> will be ignored and failing to get a response should signal to the
> client that the POSIX Extensions are not supported.
>
> A client can ask for what is supported on any open, but will likely
> only ask at mount time.
>
> If the client does not like what it is told and the user asked for
> specific options (POSIX Locks for example) that are not supported the
> client is free to refuse the mount if the user demands POSIX Locks and
> the server does not support them.
>
> 2. When a client has specified a POSIX open and the server honored it,
> it expects CASE-SENSITIVE file-name handling and it can subsequently
> submit an SMB2_FILEINFO_POSIX requests on a GET INFO, SET INFO or
> QUERY DIRECTORY request and it will get the specified POSIX info back.
>
> 3. To reduce round trips and thus provide better performance, clients
> can compound requests. For example, to get the attributes on a file a
> client can do a compounded CREATE with POSIX semantics, a GET INFO and
> a CLOSE. This takes one round trip instead of three.
>
> Here is the specification as it stands.
>
> 1. The client needs to identify whether or not UNIX extensions are
> offered by the server. To do this, it should open the root of the
> share (or, indeed, any path) and send the SMB2_POSIX_V1_CAPS create context.
>
> The client will do this with a POSIX CREATE CONTEXT defined in this manner:
>
> #define SMB2_POSIX_V1_CAPS "\x01\x35\x26\x34\x21\x29\x12\x49\x25\x86\x44\x77\x9
> 4\x11\x45\x31"
>
> struct posix_v1_create_context_request {
>         uint32_t version;    /* Must be 1 */
>         uint32_t request;   /* Must be the bits defined below */
> };
>
> The following bits are defined for the request:
>
>    0x001 POSIX_FILE_SEMANTICS_REQUESTED (case sensitive etc.)
>    0x100 REPORT_POSIX_CAPABILITIES (tells client what is supported)
>
> The response will be:
>
> struct posix_v1_create_context_response {
>         uint32_t version;  /* Must be 1 */
>         uint32_t supported_features;
> };
>
> If REPORT_POSIX_CAPABILITIES was present, the client will send back in
> a CREATE CONTEXT reply a bit-mask with one or more of the following
> bits:
>
>   0x0000001 Case sensitive file names
>   0x0000002 Posix byte-range locks
>   0x0000004 Altered OPEN/UNLINK semantics
>   0x0000008 No path mapping, no UNC conversion?
>   0x0000010 Can receive ACLs in a SETSD otherwise use UID/GID in SETINFO
>   0x0000020 Supports SMB_FILEINFO_POSIX in GET INFO, SET INFO  and
> QUERY DIRECTORY
>   0x0000040 Supports POSIX ACLs
>
> If REPORT_POSIX_CAPABILITIES was not requested in the
> create_context_request, supported bits will be zero.
>
> If the CREATE CONTEXT is not recognized, the server will ignore it and
> the client must assume that no POSIX features are supported.
>
> If the client requested POSIX_FILE_SEMANTICS and they are accepted by
> the server, it will apply all that it is capable of, including
> CASE_SENSITIVE file names.
>
> 2. It the server supports SMB_FILEINFO_POSIX in GET INFO, SET INFO or
> QUERY DIRECTORY, the client can use these and info levels from 0 to
> whatever to retrieve, set, etc, UNIX INFO, the client can use those to
> retrieve or set etc UNIX info.
>
> When a server sends a GET INFO, SET INFO or QUERY DIRECTORY with a
> SMB_FILEINFO_POSIX type, it can use one of the following levels:
>
> #define SMB2_QUERY_FILE_UNIX_BASIC        0x00 /* Also for SET */
> #define SMB2_QUERY_FILE_UNIX_LINK           0x01
> #define SMB2_QUERY_FILE_UNIX_HLINK         0x03
> #define SMB2_QUERY_POSIX_ACL                    0x04
> #define SMB2_QUERY_POSIX_XATTR               0x05
> #define SMB2_QUERY_POSIX_ATTR_FLAGS  0x06
> #define SMB2_QUERY_POSIX_PERMISSIONS 0x07
> #define SMB2_QUERY_POSIX_LOCKS              0x08
> #define SMB2_QUERY_POSIX_QUERY_INFO2 0x20B
>
> These also apply to SET INFO operations. There are two path based
> operations that are currently defined for the CIFS POSIX extensions
> that I suspect are not needed.
>
> This represents a very small and well contained set of changes to
> Samba that implements what is needed, I think and does not put an
> undue burden on the client.
>
> I will clean up the tests I have and the support code over the next
> few days and post it, but I am interested in feedback on this proposal
> so I can clean it up and propose it to Microsoft.

OK, quite a few things are still missing.

1. Definition of SMB2_FILEINFO_POSIX
2. Definitions of the structures returned, even if they are only
copies of existing stuff. They should be in the format other SMB specs
us.
3. Specification of error values returned and when.

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


More information about the samba-technical mailing list