'Re: [cifs-protocol] 112101850229631] Scope of a File.LeaseKey on the client'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] 112101850229631] Scope of a File.LeaseKey on the client
From:       Tarun Chopra <Tarun.Chopra () microsoft ! com>
Date:       2012-10-29 20:54:56
Message-ID: DDBD45A4D7FADF4C892462CA15CEB5B432A3491A () TK5EX14MBXC296 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]

Hi Metze

Kindly let us know if you have any other queries on this issue. If not, shall we go \
ahead and close the case. Please confirm.

Thanks
Tarun Chopra.

-----Original Message-----
From: Tarun Chopra 
Sent: Thursday, October 25, 2012 12:24 PM
To: 'Stefan (metze) Metzmacher'
Cc: MSSolve Case Email; 'cifs-protocol@cifs.org'; 'pfif@tridgell.net'
Subject: [RE: 112101850229631] Scope of a File.LeaseKey on the client

Hi Metze

Per analysis, yes, your understanding is correct on LeaseKey and pathname. In \
windows, Lease is closely tied to the path used while opening the file and so the \
client will use the same Lease when different users try to open a file using same \
path. Windows clients "assume" that the same path always refer to the same file.  So \
yes, (with or without leases), the scenario below will be broken on a Windows client. \
The same scenario would be broken even without leases in play, for example \
traditional op-locks or even without op-locks. 

Furthermore, the relationship between a "pathname" and a "lease" is purely a client \
implementation detail and is NOT mandated by the protocol. It is true that windows \
client maintains a 1:1 relationship between a pathname and a lease key.

Please let us know if this resolves your query or you require any additional \
clarification.

Thanks
Tarun Chopra

-----Original Message-----
From: Tarun Chopra 
Sent: Thursday, October 18, 2012 7:05 AM
To: Stefan (metze) Metzmacher
Cc: MSSolve Case Email; cifs-protocol@cifs.org; pfif@tridgell.net
Subject: [RE:112101850229631] Scope of a File.LeaseKey on the client

Hi Metze

Thanks for contacting Microsoft Support. We have created a case, 112101850229631, to \
track your inquiry and a support engineer will contact you to assist further.

Thanks
Tarun Chopra.

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze@samba.org] 
Sent: Thursday, October 18, 2012 12:56 AM
To: Interoperability Documentation Help; cifs-protocol@cifs.org; pfif@tridgell.net
Subject: Scope of a File.LeaseKey on the client

Hi DocHelp,

is it correct that the LeaseKey on a file is shared between different user contexts?

From 3.2.4.3 Application Requests Opening a File:

  [...]

  If the client implements the SMB 2.1 or SMB 3.0 dialect and \
Connection.SupportsFileLeasing is  TRUE, the client MUST search the GlobalFileTable \
for an entry matching one of the following:

  - The application-supplied PathName if TreeConnect.IsDfsShare is TRUE.
  - The concatenation of Connection.ServerName, TreeConnect.ShareName, and the
    application-supplied PathName, joined with pathname separators
(example: server\share\path),
    if TreeConnect.IsDfsShare is FALSE.

  If an entry is not found, a new File entry MUST be created and added to the \
GlobalFileTable and a  File.LeaseKey, as specified in section 3.2.1.5, MUST be \
assigned to the entry. File.OpenTable  MUST be initialized to an empty table and \
File.LeaseState MUST be initialized to  SMB2_LEASE_NONE.

  [...]

  If the client accesses a file through multiple paths, such as using different \
server names or share  names or parent directory names, it will create multiple File \
elements, and therefore multiple  File.LeaseKeys for the same remote file. This loses \
the performance benefits of sharing cache state  across all Opens of the same file, \
and may cause additional lease breaks to be generated, as  actions by a client \
through one path will affect caching by that client through other paths. However,  \
the impact is a matter of performance; cache correctness is preserved.

  [...]

It seems that the LeaseKey is purely tight to the full path to the file from the \
client perspective.

I guess on a terminal server where multiple users access the same path on the server, \
the LeaseKey is shared between them, is that correct?

If this is true, then this implies that each user sees the same content in a file, \
which might not be true.

E.g. in Samba we allow shares to expose different FSA level directories based on user \
account. The typical example is the "homes" share which exposes the unix home \
directory of the specific user.

I fear that we have to disable such powerful features if we want to take advantage of \
leases, otherwise the client would treat \\sambaserver\homes\commonfile.doc of user1 \
and \\sambaserver\homes\commonfile.doc of user2 as the same file.

I assume user1 and user2 should share the client_guid and lease_key, which means data \
corruption and/or security problems are very likely, if the server grants leases in \
this case.

metze

_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol

[prev in list] [next in list] [prev in thread] [next in thread] 