linux-kernel - Re: [PATCH 00/35] cifs: Fix SMB rmdir() and unlink() against Windows SMB servers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dfa557ed-eb34-4eaf-9e17-7cae221e74fd@samba.org>
Date: Mon, 1 Sep 2025 09:55:45 +0200
From: Stefan Metzmacher <metze@...ba.org>
To: Pali Rohár <pali@...nel.org>,
 Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.com>,
 ronnie sahlberg <ronniesahlberg@...il.com>, Ralph Böhme
 <slow@...ba.org>
Cc: linux-cifs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/35] cifs: Fix SMB rmdir() and unlink() against Windows
 SMB servers

Hi Pali,

> This patch series improves Linux rmdir() and unlink() syscalls called on
> SMB mounts exported from Windows SMB servers which do not implement
> POSIX semantics of the file and directory removal.
> 
> This patch series should have no impact and no function change when
> communicating with the POSIX SMB servers, as they should implement
> proper rmdir and unlink logic.

Please note that even servers implementing posix/unix extensions,
may also have windows clients connected operating on the same files/directories.
And in that case even posix clients will see the windows behaviour
of DELETE_PENDING for set disposition or on rename
NT_STATUS_ACCESS_DENIED or NT_STATUS_DIRECTORY_NOT_EMPTY.

> When issuing remove path command against non-POSIX / Windows SMB server,
> it let the directory entry which is being removed in the directory until
> all users / clients close all handles / references to that path.
> 
> POSIX requires from rmdir() and unlink() syscalls that after successful
> call, the requested path / directory entry is released and allows to
> create a new file or directory with that name. This is currently not
> working against non-POSIX / Windows SMB servers.
> 
> To workaround this problem fix and improve existing cifs silly rename
> code and extend it also to SMB2 and SMB3 dialects when communicating
> with Windows SMB servers. Silly rename is applied only when it is
> necessary (when some other client has opened file or directory).
> If no other client has the file / dir open then silly rename is not
> used.

If I 'git grep -i silly fs/smb/client' there's no hit, can you
please explain what code do you mean with silly rename?

Thanks!
metze