On 8/1/25 1:20 PM, Jean-Baptiste Denis via samba wrote:> Sorry about that and thank you for warning me. > > pcap: https://dl.pasteur.fr/fop/vkuc87yJ/file_delete_reproducer.pcap.zst > reproducer: https://dl.pasteur.fr/fop/doQKcwvv/reproducer3.shlooks like the client is doing it: after the server rightly refuses the rename in packets 102-109 (the client tries multiple times), in packet 110 the client it sets delete-on-close on the the X.sh and a bit later after the last open handle to X.sh is closed, the server rightly deletes the file. The deletion might be done by the `mv` command or it might be some code in the cifs kernel client triggered by the rename failure. I guess the next step would be to write a minimal C POSIX programm that replicates this to have full control over the application. If that still fails it must be something in the cifs client in the kernel. -slow -- SerNet Samba Team Lead https://sernet.de/ Samba Team Member https://samba.org/ Samba Support and Dev https://samba.plus/services/ SAMBA+ packages https://samba.plus/products/samba -------------- 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/attachments/20250801/20c89292/OpenPGP_signature.sig>
On Fri, 1 Aug 2025 14:19:36 +0200 Ralph Boehme via samba <samba at lists.samba.org> wrote:> On 8/1/25 1:20 PM, Jean-Baptiste Denis via samba wrote: > > Sorry about that and thank you for warning me. > > > > pcap: > > https://dl.pasteur.fr/fop/vkuc87yJ/file_delete_reproducer.pcap.zst > > reproducer: https://dl.pasteur.fr/fop/doQKcwvv/reproducer3.sh > > looks like the client is doing it: > > after the server rightly refuses the rename in packets 102-109 (the > client tries multiple times), in packet 110 the client it sets > delete-on-close on the the X.sh and a bit later after the last open > handle to X.sh is closed, the server rightly deletes the file. > > The deletion might be done by the `mv` command or it might be some > code in the cifs kernel client triggered by the rename failure. > > I guess the next step would be to write a minimal C POSIX programm > that replicates this to have full control over the application. If > that still fails it must be something in the cifs client in the > kernel. > > -slow >I don't know if this helps, but the 'mv' command works if you move the file to a non-existent file e.g. mv x XX.sh Rowland
On 01.08.2025 15:19, Ralph Boehme via samba wrote:> On 8/1/25 1:20 PM, Jean-Baptiste Denis via samba wrote: >> Sorry about that and thank you for warning me. >> >> pcap: https://dl.pasteur.fr/fop/vkuc87yJ/file_delete_reproducer.pcap.zst >> reproducer: https://dl.pasteur.fr/fop/doQKcwvv/reproducer3.sh > > looks like the client is doing it: > > after the server rightly refuses the rename in packets 102-109 (the > client tries multiple times), in packet 110 the client it sets delete- > on-close on the the X.sh and a bit later after the last open handle to > X.sh is closed, the server rightly deletes the file. > > The deletion might be done by the `mv` command or it might be some code > in the cifs kernel client triggered by the rename failure. > > I guess the next step would be to write a minimal C POSIX programm that > replicates this to have full control over the application. If that still > fails it must be something in the cifs client in the kernel.BTW, this is exactly the scenario which I reported back in Mar-2024, https://lists.samba.org/archive/samba/2024-March/248344.html FWIW. Thanks, /mjt