POSIX Extenstions for SMB2/3. An initial proposal.

Richard Sharpe realrichardsharpe at gmail.com
Tue Jun 9 20:52:14 MDT 2015


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.

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


More information about the samba-technical mailing list