SMB3 POSIX, byterange locks and close behaviour

[Ralph Boehme]

Hi folks,

while working on the part for byterange locks of the SMB3 POSIX spec, I 
noticed a problem in the protocol:

Neither MS-SMB2+ nor the SMB3 POSIX ext has a way to send a client side 
identifier for the process (like the pid) to the server. That means when 
processing SMB2-CLOSE we have no way to correlate opens by the same vs 
different applications (pids) on the client.

Suppose on the client this happens:

1. application A (pid=X on the client) opens fd1=open("file") and sets a brl
2. application A (pid=X on the client) opens another fd2=open("file") 
and sets a compatible brl
3. application B (pid=Y on the client) opens another fd3=open("file") 
and sets a compatible brl
4. application A closes fd1

According to POSIX rules we have to drop all brls on "file" when closing 
any fd on "file", but this can't be implemented on the server, as we 
have no way to tie opens from the same client side process together.

It's also not possible to implement OFD locks in the protocol, same problem.

Using OFD locks in the backend on the server doesn't help.

SMB1 had pidlow/pidhigh in the header and MS-FSA "2.1.5.8 Server 
Requests a Byte-Range Lock" has:

---8<---
The server provides:

LockKey: A 32-bit unsigned integer containing an identifier for the lock 
being obtained by a specific process.
---8<---

and this part of MS-CIFS "3.3.5.15 Receiving an SMB_COM_LOCK_BYTE_RANGE 
Request":

---8<---
Locks prevent attempts to lock, read, or write the locked portion of the 
file by other clients or PIDs from the same client.
---8<---

...implies the SMB1 server passes the PID as LockKey to the FSA layer.

SMB2+ doesn't have a PID nor has POSIX-SMB2 and I wonder if we need one, 
at least for the lock/unlock SMB2 requests. SMB2_LOCK_ELEMENT has a 
32bit reserved field which we could repurpose, but there'll be dragons, 
so we might need a different way to extend the protocol.

We also have a 32bit reserved in FilePosixInformation, that would fit 
the bill.

Thoughts? Am I missing something?

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20260316/50b142b6/OpenPGP_signature.sig>