Re: [PATCH] ksmbd: enforce the DACL permission check on delete-on-close opens
From: Namjae Jeon
Date: Wed Oct 28 2026 - 22:50:27 EST
On Thu, Oct 29, 2026 at 11:20 AM Ian Bridges <icb@xxxxxxxxxxxx> wrote:
>
> On Thu, Oct 29, 2026 at 10:38 AM Namjae Jeon <linkinjeon@xxxxxxxxxx> 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.
I will revert it in ksmbd-for-next. You can send v2 patch to the list and me.
Thanks!
>
> Thanks,
> Ian