[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:
> 
> 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.

>  	/* Handle strange delete on close create semantics. */
>  	if (create_options & FILE_DELETE_ON_CLOSE) {
> +		if (new_file_created) {
> +			status = can_set_delete_on_close(fsp,
> +						 new_dos_attributes);
> +			if (!NT_STATUS_IS_OK(status)) {
> +				int ret;
>  
> -		status = can_set_delete_on_close(fsp, new_dos_attributes);
> +				ret = SMB_VFS_UNLINK(conn, fsp->fsp_name);
> +				if (ret != 0) {
> +					DBG_INFO("Unlink of new file %s failed "
> +						 "after DELETE_ON_CLOSE check "
> +						 "returned %s: %s\n",
> +						 smb_fname_str_dbg(smb_fname),
> +						 nt_errstr(status),
> +						 strerror(errno));
> +				}
> +			}
> +		} 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. */

I have to NAK the above I'm afraid. There's an inherent race
condition to do with calling SMB_VFS_UNLINK() even if we just
created the file.