[PATCHES][BUG 13673] smbd: Fix DELETE_ON_CLOSE behaviour on files with READ_ONLY attribute
Jeremy Allison
jra at samba.org
Fri Nov 2 22:47:40 UTC 2018
On Fri, Nov 02, 2018 at 03:33:28PM -0700, Christof Schmitt wrote:
> >
> > Something like this ?
> >
> > diff --git a/source3/smbd/open.c b/source3/smbd/open.c
> > index d6359aac0c6..45ac33483d1 100644
> > --- a/source3/smbd/open.c
> > +++ b/source3/smbd/open.c
> > @@ -3732,8 +3732,13 @@ static NTSTATUS open_file_ntcreate(connection_struct *conn,
> >
> > /* Handle strange delete on close create semantics. */
> > if (create_options & FILE_DELETE_ON_CLOSE) {
> > -
> > - status = can_set_delete_on_close(fsp, new_dos_attributes);
> > + if (info == FILE_WAS_CREATED) {
> > + status = can_set_delete_on_close(fsp,
> > + new_dos_attributes);
> > + } else {
> > + status = can_set_delete_on_close(fsp,
> > + existing_dos_attributes);
> > + }
> >
> > if (!NT_STATUS_IS_OK(status)) {
> > /* Remember to delete the mode we just added. */
> >
>
> Yes. The attached patches cover both cases now. I also discovered that
> when NT_STATUS_CANNOT_DELETE is returne for a new file, the file is
> still created. The easiest fix seems to be to unlink again. The question
> here is whether there is a good way to move the check for the new file
> case before actually creating the file.
I'm assuming that you mean "when NT_STATUS_CANNOT_DELETE is returne for a new file, the file is
still created" - means it should not be.
"The easiest fix seems to be to unlink again" - actually no,
the better fix is when we know we're creating a new file,
then ensure that fsp is set up enough to allow can_set_delete_on_close()
to make the correct decision *before* creating the new file.
We should never detete a file once created I think.
Jeremy.
More information about the samba-technical
mailing list