Re: [PATCH] ksmbd: enforce the DACL permission check on delete-on-close opens

[Ian Bridges <icb@fastmail.org>]

On Thu, Oct 29, 2026 at 10:38 AM Namjae Jeon <linkinjeon@kernel.org> wrote:
> This patch causes smb2.acls.INHERITANCE failure in smbtorture test.
> Can you check it ?
>
> failure: INHERITANCE [
> (../../source4/torture/smb2/acls.c:1054) Incorrect status
> NT_STATUS_OBJECT_NAME_COLLISION - should be NT_STATUS_OK
> ]

Thanks for running this. I can reproduce it with smbtorture 4.22, and it
passes without this patch.

The inheritance checks themselves aren't what fails. It's the rmdir at
the end of the i == 1 iteration, which the test doesn't check, so it
shows up as a collision when the next iteration creates the same
directory.

In that iteration the parent directory's DACL is

  ALLOW CREATOR OWNER  WRITE_DATA   (object inherit)
  ALLOW Everyone       full access  (no inheritance)

so the new subdirectory ends up with no ACE that grants DELETE. Windows
and Samba still let you delete it, because the parent grants
FILE_DELETE_CHILD. ksmbd doesn't have that rule, so even a plain DELETE
open of that subdirectory fails today. Before this patch, the
delete-on-close open that smb2_util_rmdir() uses skipped the DACL check
and got through anyway. This patch sends that open through the DACL
check, and the check denies it.

So the test is right. What's missing is the FILE_DELETE_CHILD rule.
Reverting this patch would just hide that again, and reopen the
delete-on-close bypass.

I have a fix that treats FILE_DELETE_CHILD on the parent as a second way
to get DELETE, like Samba's parent_override_delete(). It only uses a
parent's stored DACL, and never looks above the share root. With it,
INHERITANCE passes, the rest of smb2.acls and smb2.delete-on-close-perms
are unchanged, and the cases this patch blocks stay blocked.

Would you like the fix as a separate patch on top of this one? Or, if
you'd rather not keep this one in ksmbd-for-next for now, I can resend
both as a two-patch series, fix first, so they reach stable together.

Thanks,
Ian