[PATCHES][BUG 13673] smbd: Fix DELETE_ON_CLOSE behaviour on files with READ_ONLY attribute

[Jeremy Allison]

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.