Created attachment 18268 [details] tcpdump of mv operation It looks like samba server does not check if the destination file of rename operation is locked. The source is checked, but not the destination. So samba allows to overwrite a file which is opened and locked by another client, and to make clients misbehave. Also, due to delayed delete and combining it with rename, samba allows unexpected silent data loss, - hence the severity of this bug report. Having Samba server S, a Windows client W, and a Linux client L, and two files, file.exe and file.new. 1. On W, mount samba share and lock file.exe (for example, start the executable). 2. On L, mount the same samba share using cifs, and do a simple `mv file.new file.exe'. This will succeed, despite the fact that file.exe is open and locked on W. S does not check if destination file is locked. 3. Windows is unable to open file.exe anymore, returning "Invalid parameter" error at open. Attached are tcpdump and level8 debug log from samba resulted from just the mv operation (mounted the filesystem over loopback on the same server). For unexpected data loss, this issue is combined with delayed delete, like this: 1. On W, mount samba share and lock file.exe 2. On L, mount samba share and run `rm file.exe'. This will hang. Interrupt the rm process. 3. On L. do `mv file.new file.exe' 4. On W, release the lock. 5. Watch file.exe (which is now file.new already!) is deleted by S.
Created attachment 18269 [details] samba level8 log of the rename operation
The observed behavior seems not dependent on the linux client kernel version, - tried 6.1, 5.10 and 6.6 kernels, all behave the same way.
In the traces, file.exe is xml_upload.exe, and file.new is xml_upload.exe.1 - just a random executable I found there.
I have a plan for this. In the SMB2 rename code path, before we take any locks we should attempt an SMB_VFS_CREATE_FILE() on the destination file with no allowed sharing (FILE_SHARE_NONE), DELETE access and create options FILE_DELETE_ON_CLOSE. If this open fails then we know some other node has the target file open and we should deny the rename. We need some torture tests for Windows so we understand the desired behavior first (what happens with target file leased etc.). We might not be able to completely reproduce Windows behavior (lease breaks etc.) but this should fix the immediate problem.
I'm currently searching for any way to update files from linux, through samba/cifs, maybe using smbclient, anything. It looks like samba currently is unable to update a file without adding a windows machine to the mix. Right now I'm mounting samba resource on a (virtual) windows machine, export this filesystem from windows back to this same linux machine, mounting it using cifs, and updating files in there, - this FINALLY works. The VM can be run on the same linux machine so it is still sort of self-contained. But it's utter idiocy that we don't have any better way to update files...
Working on a fix.
We also currently fail to check for H-lease breaks in several scenarios: - rename source: recursively break H-leases in the source directory - rename destination - unlink - tree disconnect with pending initial-delete-on-close - session logoff with pending initial-delete-on-close - TCP disconnect with pending initial-delete-on-close
This bug was referenced in samba master: 3ce664243d677017ac5e13679dde4ae8b1c4f6ba ddd8ca35b28578bb92cb7c5b97201c1ec1498f05 a771506120f4ab08d5f2c2c58e1ca78b6e1b4aa1 00754add3cdcd325c1beb527f252069dd6a3af82 f9c9593225d48706cbed698efc1b2b7f6760966d aaa9e60ddbcd7c905699739c9d70cb71bc2f74bc 67f560133744eaee9793562f0b48a67ea4221243 6cc25159d5a0b5be024629467b866939dd667036 9e13780a8fc48ae8eeda9b14fe72e828166edb3d bb940c5bb66c3773726f11f223a3da3d877ab213 644fab6c2aac4316d8310cb0c8a8d1e10e54230e ee5d3c63f60ec4d353d799f9427b5325de4cdccd f86208d272cfa0ce6753b02d3f5b1cce4fd91e2e 28f9c520fa412745fa1d32d8650ed01d3e95107f 5305e361942c0893143abf74fd832c71fb844643 9b4ff5ff28e35d1f7837b44a2b47c3ee2691b3b0 bd120224dbaf531c1f028ea4a3fc8a0b200dce6a 8d744549420b3be4b4e01ac7165e04ab845ada93 79d7d26fd193103ae74d754c5fbe851deeb1d9a5 db3933da6ca1ae63a2c322cf78e83699e867c6ba 7218bffc535d743dfe42595ceeaa5f36283fb321 d6b684120f324ce69707806218a1a3fc7e6febba c78ffae3b3a93cf31bb826f6a66fb955385e11c5 aee574aef90857126caedf9db4d287cf579b4ccb 6703538126f6b8ab732714eb1e24b8db03d4594f ac3a74b459338da1b129549cdacfd8925f5a8359 2b745ad9f691863812e280504f96d2faa8aeac4d a611e6d4027b261e666e03532089de7af10c9cf5 49ea685e2ae134ed0484a396205e1d10935fe5f3 e21effb2dd27c8ea4700abd5e8884e312988f61e